Re: [edk2] OVMF broken under Xen (in PCI initialisation)

[Ni, Ruiyu]

Regards,
Ray

>-Original Message-
>From: Gary Lin [mailto:g...@suse.com]
>Sent: Wednesday, April 27, 2016 12:29 PM
>To: Ni, Ruiyu 
>Cc: edk2-devel@lists.01.org; Xen Devel 
>Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>
>On Tue, Apr 26, 2016 at 09:40:42AM +, Ni, Ruiyu wrote:
>> Gary,
>> I can reproduce the issue and have debugged to get the reason.
>> In MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c:
>> PciEnumeratorLight() calls PciRootBridgeIo->Configuration()
>> while the Configuration returns EFI_UNSUPPORTED resulting
>> the PciBus driver exits earlier.
>> You could try to manually set MinBus to 0 and MaxBus to 0xFF.
>>
>Do you mean to set MinBus and MaxBus in PciGetBusRange() ?
>Should I also keep the EFI_UNSUPPORTED code in Configuration() ?
Keep returning EFI_UNSUPPORTED in Configuration() and set
MinBus/MaxBus in PciGetBusRange().

>
>> The second change you need to make is in PciIo.c:
>> Change GetMmioAddressTranslationOffset() to return 0 instead
>> of -1 when error occurs
>>
>
>Should I also remove "ASSERT (FALSE);" ?


ASSERT() won't be hit.

>
>Cheers,
>
>Gary Lin
>
>> With the above 2 changes, can you check whether the system can
>> boot?
>>
>> If it can boot, then we need to think about what the proper fix is.
>> For OVMF above Xen, the PCI resources are assigned by Xen other than
>> PciBus driver. So PciRootBridgeIo->Configuration() doesn't know
>> the resource assignment information.
>> With old PciHostBridge driver, the Configuration() returns BUS resource
>> descriptor with MinBus = MaxBus = 0 (default value), so that the PciBus
>> driver can detect all devices in BUS 0, but I guess devices in BUS 1+ cannot
>> be detected.
>>
>> Does Xen pass the resource assignment information through some memory
>> blob to firmware? If yes, we could think about let PciHostBridgeLib pass that
>> information to PciHostBridge driver. If no, we also could let 
>> PciHostBridgeLib
>> collect the information (IO/MEM/BUS resource assignment) and pass that
>> to PciHostBridgeDxe driver.
>>
>> And we need to have a way to tell PciHostBridgeDxe the resource information
>> passed from PciHostBridgeLib is available resource to assign, or already 
>> allocated.
>> Maybe just depends on the PcdPciBusDisableEnumeration. still thinking.
>>
>>
>> Regards,
>> Ray
>>
>> >-Original Message-
>> >From: Gary Lin [mailto:g...@suse.com]
>> >Sent: Tuesday, April 26, 2016 4:40 PM
>> >To: Ni, Ruiyu 
>> >Cc: edk2-devel@lists.01.org; Xen Devel 
>> >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>> >
>> >On Tue, Apr 26, 2016 at 08:19:49AM +, Ni, Ruiyu wrote:
>> >> Gary,
>> >> Maybe the system boots to Shell well but the video isn't initialized 
>> >> properly.
>> >> Can you build the firmware using "-D DEBUG_ON_SERIAL_PORT" switch and
>> >> give me the boot log?
>> >>
>> >Hi Ray,
>> >
>> >I already did and it's how I make the firmware spit the log :-(
>> >
>> >Thanks,
>> >
>> >Gary Lin
>> >
>> >> Regards,
>> >> Ray
>> >>
>> >> From: Gary Lin [mailto:g...@suse.com]
>> >> Sent: Tuesday, April 26, 2016 3:35 PM
>> >> To: Ni, Ruiyu 
>> >> Cc: Anthony PERARD ; edk2-devel@lists.01.org; 
>> >> Xen Devel 
>> >> Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>> >>
>> >> On Tue, Apr 26, 2016 at 06:43:56AM +, Ni, Ruiyu wrote:
>> >> >
>> >> >
>> >> > Regards,
>> >> > Ray
>> >> >
>> >> > >-Original Message-
>> >> > >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> >> > >Anthony PERARD
>> >> > >Sent: Friday, April 22, 2016 10:48 PM
>> >> > >To: edk2-devel@lists.01.org
>> >> > >Cc: Xen Devel >
>> >> > >Subject: [edk2] OVMF broken under Xen (in PCI initialisation)
>> >> > >
>> >> > >Hi,
>> >> > >
>> >> > >Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci 
>> >> > >root
>> >> > >bridge does not finish to initialize and breaks under Xen.
>> >> > >
>> >> > >There are several issue probably due to the use of
>> >> > >PcdPciDisableBusEnumeration=TRUE.
>> >> > >
>> >> > >First one:
>> >> > >ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): 
>> >> > >Bridge->Mem.Limit <
>> >0x0001ULL
>> >> > >
>> >> > >This patch would fix the first assert:
>> >> > >diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
>> >> > >index 7fa9019..15ec7a7 100644
>> >> > >--- a/OvmfPkg/PlatformPei/Xen.c
>> >> > >+++ b/OvmfPkg/PlatformPei/Xen.c
>> >> > >@@ -227,5 +227,11 @@ InitializeXen (
>> >> > >
>> >> > >   PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
>> >> > >
>> >> > >+  // Values from hvmloader
>> >> > >+#define PCI_MEM_END 0xFC00
>> >> > >+#define HVM_BELOW_4G_MMIO_START 0xF000
>> >> > >+  PcdSet64 

Re: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when certificate is added to store multiple times

[Wu, Jiaxin]

Samer,

I have merged the pull request, but seems it's not a clean way to contribution 
the patch (with another merge operation).  I would like to commit the patch 
manually next time.

Thanks.
Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of El-
> Haj-Mahmoud, Samer
> Sent: Wednesday, April 27, 2016 12:36 AM
> To: Wu, Jiaxin ; Carsey, Jaben
> 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when certificate is
> added to store multiple times
> 
> Does not look like I have write permission to edk2-staging... I sent a 
> separate
> email with question on the write access permissions for edk2-staging
> 
> I also created a pull request against the edk2-staging/https-tls branch:
> https://github.com/tianocore/edk2-staging/pull/1
> 
> 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wu, Jiaxin
> Sent: Monday, April 25, 2016 8:54 PM
> To: El-Haj-Mahmoud, Samer ; Carsey,
> Jaben 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when certificate is
> added to store multiple times
> 
> Please let me know whether you can commit the patch:).
> 
> Thanks.
> Jiaxin
> 
> From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
> Sent: Tuesday, April 26, 2016 9:41 AM
> To: Carsey, Jaben ; Wu, Jiaxin
> 
> Cc: edk2-devel@lists.01.org; Palmer, Thomas 
> Subject: RE: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when certificate is
> added to store multiple times
> 
> Thanks for the prefix tip! Will try that next time.
> 
> I don't know if I have write access to the branch. I will give it a try.
> 
> 
> 
> 
> -Original Message-
> From: Wu, Jiaxin [jiaxin...@intel.com]
> Received: Monday, 25 Apr 2016, 7:43PM
> To: Carsey, Jaben [jaben.car...@intel.com]; El-Haj-Mahmoud, Samer
> [samer.el-haj-mahm...@hpe.com]
> CC: edk2-devel@lists.01.org [edk2-
> de...@lists.01.org]; Palmer, Thomas [thomas.pal...@hpe.com]
> Subject: RE: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when certificate is
> added to store multiple times Hi Samer,
> 
> I think the prefix with " staging/branch][PATCH " should be good to the
> staging patch subject.
> 
> For example:
> *git format-patch  --subject-prefix="staging/HTTPS-TLS][PATCH"*
> 
> Then, you will get the patch with "[staging/HTTPS-TLS][PATCH]" subject.
> 
> The patch fix is good to me. Thanks for this contribution.
> 
> Reviewed-by: Jiaxin Wu >
> 
> BTW, Do you commit the patch by yourself or need I help to check in the
> patch?
> 
> Best Regards!
> Jiaxin
> 
> > -Original Message-
> > From: Carsey, Jaben
> > Sent: Tuesday, April 26, 2016 4:00 AM
> > To: El-Haj-Mahmoud, Samer
> >  mahm...@hpe.com>>
> > Cc: edk2-devel@lists.01.org; Wu,
> > Jiaxin >; Palmer,
> > Thomas >
> > Subject: Re: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when
> > certificate is added to store multiple times
> >
> > Ok. You can rb me, but I don't maintain that pkg so...
> >
> > Reviewed-by Jaben Carsey
> > >
> >
> > -Jaben
> >
> > > On Apr 25, 2016, at 11:17 AM, El-Haj-Mahmoud, Samer  > mahm...@hpe.com> wrote:
> > >
> > > Thanks Jaben. I did notice this and tried to submit the patch with
> > > the
> > modified subject (using git send-email with both --subject and
> > --compose), but that didn't work for some reason.
> > >
> > > Some answers below...
> > >
> > >
> > > -Original Message-
> > > From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> > > Sent: Monday, April 25, 2016 12:54 PM
> > > To: El-Haj-Mahmoud, Samer
> > >  mahm...@hpe.com>>;
> > > edk2-devel@lists.01.org
> > > Cc: El-Haj-Mahmoud, Samer
> > >  mahm...@hpe.com>>;
> > > Wu,
> > Jiaxin
> > > >; Carsey, Jaben
> > > >
> > > Subject: RE: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when
> > > certificate is added to store multiple times
> > >
> > > Samer,
> > >
> > > Note: This is not in the EDK2 yet, but in the staging... change
> > > [PATCH] to [Staging/HTTPS-TLS PATCH] (or something like that per the
> > > rules...)
> > >
> > > 2 questions inline also.
> > >
> > > -Jaben
> > >
> > >> -Original Message-
> > >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > >> Of Samer 

Re: [edk2] OVMF broken under Xen (in PCI initialisation)

[Gary Lin]

On Tue, Apr 26, 2016 at 09:40:42AM +, Ni, Ruiyu wrote:
> Gary,
> I can reproduce the issue and have debugged to get the reason.
> In MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c:
> PciEnumeratorLight() calls PciRootBridgeIo->Configuration()
> while the Configuration returns EFI_UNSUPPORTED resulting
> the PciBus driver exits earlier.
> You could try to manually set MinBus to 0 and MaxBus to 0xFF.
> 
Do you mean to set MinBus and MaxBus in PciGetBusRange() ?
Should I also keep the EFI_UNSUPPORTED code in Configuration() ?

> The second change you need to make is in PciIo.c:
> Change GetMmioAddressTranslationOffset() to return 0 instead
> of -1 when error occurs
> 

Should I also remove "ASSERT (FALSE);" ?

Cheers,

Gary Lin

> With the above 2 changes, can you check whether the system can
> boot?
> 
> If it can boot, then we need to think about what the proper fix is.
> For OVMF above Xen, the PCI resources are assigned by Xen other than
> PciBus driver. So PciRootBridgeIo->Configuration() doesn't know
> the resource assignment information.
> With old PciHostBridge driver, the Configuration() returns BUS resource
> descriptor with MinBus = MaxBus = 0 (default value), so that the PciBus
> driver can detect all devices in BUS 0, but I guess devices in BUS 1+ cannot
> be detected.
> 
> Does Xen pass the resource assignment information through some memory
> blob to firmware? If yes, we could think about let PciHostBridgeLib pass that
> information to PciHostBridge driver. If no, we also could let PciHostBridgeLib
> collect the information (IO/MEM/BUS resource assignment) and pass that
> to PciHostBridgeDxe driver.
> 
> And we need to have a way to tell PciHostBridgeDxe the resource information
> passed from PciHostBridgeLib is available resource to assign, or already 
> allocated.
> Maybe just depends on the PcdPciBusDisableEnumeration. still thinking.
> 
> 
> Regards,
> Ray
> 
> >-Original Message-
> >From: Gary Lin [mailto:g...@suse.com]
> >Sent: Tuesday, April 26, 2016 4:40 PM
> >To: Ni, Ruiyu 
> >Cc: edk2-devel@lists.01.org; Xen Devel 
> >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
> >
> >On Tue, Apr 26, 2016 at 08:19:49AM +, Ni, Ruiyu wrote:
> >> Gary,
> >> Maybe the system boots to Shell well but the video isn't initialized 
> >> properly.
> >> Can you build the firmware using "-D DEBUG_ON_SERIAL_PORT" switch and
> >> give me the boot log?
> >>
> >Hi Ray,
> >
> >I already did and it's how I make the firmware spit the log :-(
> >
> >Thanks,
> >
> >Gary Lin
> >
> >> Regards,
> >> Ray
> >>
> >> From: Gary Lin [mailto:g...@suse.com]
> >> Sent: Tuesday, April 26, 2016 3:35 PM
> >> To: Ni, Ruiyu 
> >> Cc: Anthony PERARD ; edk2-devel@lists.01.org; 
> >> Xen Devel 
> >> Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
> >>
> >> On Tue, Apr 26, 2016 at 06:43:56AM +, Ni, Ruiyu wrote:
> >> >
> >> >
> >> > Regards,
> >> > Ray
> >> >
> >> > >-Original Message-
> >> > >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> >> > >Anthony PERARD
> >> > >Sent: Friday, April 22, 2016 10:48 PM
> >> > >To: edk2-devel@lists.01.org
> >> > >Cc: Xen Devel >
> >> > >Subject: [edk2] OVMF broken under Xen (in PCI initialisation)
> >> > >
> >> > >Hi,
> >> > >
> >> > >Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci 
> >> > >root
> >> > >bridge does not finish to initialize and breaks under Xen.
> >> > >
> >> > >There are several issue probably due to the use of
> >> > >PcdPciDisableBusEnumeration=TRUE.
> >> > >
> >> > >First one:
> >> > >ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): 
> >> > >Bridge->Mem.Limit <
> >0x0001ULL
> >> > >
> >> > >This patch would fix the first assert:
> >> > >diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
> >> > >index 7fa9019..15ec7a7 100644
> >> > >--- a/OvmfPkg/PlatformPei/Xen.c
> >> > >+++ b/OvmfPkg/PlatformPei/Xen.c
> >> > >@@ -227,5 +227,11 @@ InitializeXen (
> >> > >
> >> > >   PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
> >> > >
> >> > >+  // Values from hvmloader
> >> > >+#define PCI_MEM_END 0xFC00
> >> > >+#define HVM_BELOW_4G_MMIO_START 0xF000
> >> > >+  PcdSet64 (PcdPciMmio32Base, HVM_BELOW_4G_MMIO_START);
> >> > >+  PcdSet64 (PcdPciMmio32Size, PCI_MEM_END - HVM_BELOW_4G_MMIO_START);
> >> > >+
> >> > >   return EFI_SUCCESS;
> >> > > }
> >> > >
> >> > >
> >> > >But that not enough, next assert is:
> >> > >ASSERT MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c(807): 
> >> > >RootBridge != ((void *) 0)
> >> > >
> >> > >I have worked around this one with the following patch. That would
> >> > >correspond to how the former implementation in OvmfPkg was initializing 
> >> > >the
> >> > >struct. Maybe a 

Re: [edk2] HMAC calculation clarification for TPM 1.2

[Long, Qin]

David,

I think your original understanding should be correct. (I am not 100% sure. 
Still need to double-confirm.)
For one OSAP session, 
sharedSecret = HMAC(key.usageAuth, nonceEvenOSAP, nonceOddOSAP)
The shared secret will be calculated by HMACing the TPM OSAP nonce (nonceEven) 
and the caller OSAP nonce (nonceOdd). The HMAC key will be key.usageAuth. The 
common process should look like:
HMAC_Init (Ctx, key.usageAuth);
HMAC_Update (Ctx, nonceEvenOSAP);
HMAC_Update (Ctx, nonceOddOSAP);
HMAC_Final (Ctx, sharedSecret)

So the concatenation should be right here. 

Not sure if any other issues for the wrong result, e.g. data order, key auth 
data, etc.  I just ever validated some other TPM 1.2 commands with auth 
requirements before. 


Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> David Van Arnem
> Sent: Wednesday, April 27, 2016 5:57 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] HMAC calculation clarification for TPM 1.2
> 
> Hi all,
> 
> I don't know if this is the correct place for this question, but I'm hoping
> someone can provide insight.
> 
> I'm trying to calculate authorization HMACs for authenticated commands
> with a TPM 1.2 from an EFI application, but I have not been able to get the
> correct values the TPM expects.  The TPM uses RFC 2104 for its HMAC
> calculations:
> 
> HMAC = H(K XOR opad, H(K XOR ipad, text))
> 
> where
> 
> H - SHA1
> K - key or AuthData
> ipad - B bytes of 0x36, where B is the block length, 64 opad - B bytes of 0x5C
> 
> When the TPM 1.2 Spec, Part 1 Design Principles (page 75), says:
> 
> sharedSecret = HMAC(key.usageAuth, nonceEvenOSAP, nonceOddOSAP)
> 
> How is this translated to the RFC 2104 equation, specifically the "text"
> variable?  I tried:
> 
> text = nonceEvenOSAP || nonceOddOSAP (|| concatenation)
> 
> but that did not work.  I'm wondering if instead it should be:
> 
> text = SHA1(nonceEvenOSAP) || nonceOddOSAP
> 
> which more closely matches the format for AuthData HMACs associated with
> an OSAP/OIAP session.  I would like clarification on this before I implement 
> it,
> since it is the key for other HMACs.
> 
> Thanks in advance!
> 
> --
> Thanks,
> David
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for image verification failures

[Zhang, Chao B]

Please see my comments below in [Chao]

The If{} else{} logic for debug log makes ImageVerificationLib logic more 
complex and less readable.
My suggestion is to direct report image signature against DBX/DBT, image 
signature against DB/DBT, image hash against DB/DBX result in debug log.
User can get clear log from each verification steps and find where the problem 
is happening.



Thanks & Best regards
Chao Zhang


-Original Message-
From: Cinnamon Shia [mailto:cinnamon.s...@hpe.com]
Sent: Wednesday, April 27, 2016 12:52 AM
To: edk2-devel@lists.01.org
Cc: ler...@redhat.com; samer.el-haj-mahm...@hpe.com; Zhang, Chao B; Cinnamon 
Shia
Subject: [PATCH v3] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for 
image verification failures

Add DEBUG messages in DxeImageerificationLib to help debug Secure Boot image 
verification failures

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
>
Reviewed-by: Samer EL-Haj-Mahmoud >
---
 .../DxeImageVerificationLib.c  | 49 ++
 1 file changed, 41 insertions(+), 8 deletions(-)

diff --git 
a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c 
b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
index 4b4d3bf..ee94dce 100644
--- a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
+++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLi
+++ b.c
@@ -13,6 +13,7 @@
   untrusted PE/COFF image and validate its data structure within this image 
buffer before use.

 Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2016 Hewlett Packard Enterprise Development LP
 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 @@ -71,6 +72,8 @@ 
HASH_TABLE mHash[] = {
   { L"SHA512", 64, [32], 9, Sha512GetContextSize, Sha512Init, 
Sha512Update, Sha512Final}  };

+EFI_STRING mHashTypeStr;
+
 /**
   SecureBoot Hook for processing image verification.

@@ -340,6 +343,7 @@ HashPeImage (
 return FALSE;
   }

+  mHashTypeStr = mHash[HashAlg].Name;
   CtxSize   = mHash[HashAlg].GetContextSize();

   HashCtx = AllocatePool (CtxSize);
@@ -1782,14 +1786,16 @@ ImageVerificationInAuditMode (
   UINT32   OffSet;
   CHAR16   *FilePathStr;
   UINTNSignatureListSize;
+  BOOLEAN  SigAcceptedByCertsInDb;

-  SignatureList = NULL;
-  WinCertificate= NULL;
-  SecDataDir= NULL;
-  PkcsCertData  = NULL;
-  FilePathStr   = NULL;
-  Action= EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED | 
EFI_IMAGE_EXECUTION_INITIALIZED;
-  Status= EFI_ACCESS_DENIED;
+  SignatureList  = NULL;
+  WinCertificate = NULL;
+  SecDataDir = NULL;
+  PkcsCertData   = NULL;
+  FilePathStr= NULL;
+  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED | 
EFI_IMAGE_EXECUTION_INITIALIZED;
+  Status = EFI_ACCESS_DENIED;
+  SigAcceptedByCertsInDb = FALSE;


   //
@@ -1873,6 +1879,7 @@ ImageVerificationInAuditMode (
 //
 // The information can't be got from the invalid PeImage
 //
+DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid.
+ Cannot retrieve image information.\n"));
 goto END;
   }

@@ -1896,6 +1903,7 @@ ImageVerificationInAuditMode (
 //
 // It is not a valid Pe/Coff file.
 //
+DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Not a valid PE/COFF
+ image.\n"));
 Status = EFI_ACCESS_DENIED;
 goto END;
   }
@@ -1942,6 +1950,7 @@ ImageVerificationInAuditMode (
 // and not be reflected in the security data base "dbx".
 //
 if (!HashPeImage (HASHALG_SHA256)) {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Failed to hash
+ this image using %s.\n", mHashTypeStr));
   Status = EFI_ACCESS_DENIED;
   goto END;
 }
@@ -1955,7 +1964,14 @@ ImageVerificationInAuditMode (
   //
   if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
mImageDigest, , mImageDigestSize)) {
 Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
EFI_IMAGE_EXECUTION_INITIALIZED;
+  } else {
+//
+// Image Hash is not in DB/DBX
+//
+DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not
+ signed and %s hash of image is not found in DB/DBX.\n",
+ mHashTypeStr));
   }
+} else {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not
+ signed and %s hash of image is rejected by DBX.\n", mHashTypeStr));
 }

 //
@@ -2029,7 +2045,9 @@ ImageVerificationInAuditMode (
 // Check the digital signature against the valid certificate in allowed 
database 

Re: [edk2] [PATCH v2] MdeModulePkg: Export ConfigResp only for form Package after ReadyToBoot

[El-Haj-Mahmoud, Samer]

Reviewed-by: Samer El-Haj-Mahmoud 


> -Original Message-
> From: Bi, Dandan
> Sent: Tuesday, April 26, 2016 11:03 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming; Dong, Eric
> Subject: [PATCH v2] MdeModulePkg: Export ConfigResp only for form 
> Package after ReadyToBoot
> 
> The Hii runtime support feature will export the content of HiiDatabase 
> and the ConfigResp string to runtime buffer after ReadyToBoot event is 
> triggered. If some drivers add/update/remove packages from Hiidatabase 
> after ReadyToBoot:
> Originally we will both export the content of HiiDatabase and the 
> ConfigResp string for all packages.
> But now after investigation, we found only for form packages need to 
> export the content of HiiDatabase and the ConfigResp string, for other 
> packages just need to export the content of HiiDatabase.
> Now to enhance this logic.
> 
> Notes:
>   v1->v2:
>   - Modify the subject.
>   - Close the ReadyToBoot event.
>   - Add the check (whether need to export ConfigResp) in 
> HiiGetConfigurationSetting(),
> doesn't update the caller logic.
> 
> Cc: Liming Gao 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> Reviewed-by: Eric Dong 
> ---
>  MdeModulePkg/Universal/HiiDatabaseDxe/Database.c   | 64
> +++---
>  .../Universal/HiiDatabaseDxe/HiiDatabaseEntry.c|  2 +
>  2 files changed, 58 insertions(+), 8 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> b/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> index def1eb7..d1eb881 100644
> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> @@ -17,10 +17,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, 
> EITHER EXPRESS OR IMPLIED.
> 
>  EFI_HII_PACKAGE_LIST_HEADER*gRTDatabaseInfoBuffer = NULL;
>  EFI_STRING gRTConfigRespBuffer= NULL;
>  UINTN  gDatabaseInfoSize = 0;
>  UINTN  gConfigRespSize = 0;
> +BOOLEANgExportConfigResp = TRUE;
> 
>  /**
>This function generates a HII_DATABASE_RECORD node and adds into 
> hii database.
>This is a internal function.
> 
> @@ -737,11 +738,20 @@ RemoveFormPackages (
> 
>  RemoveEntryList (>IfrEntry);
>  PackageList->PackageListHdr.PackageLength -= Package-
> >FormPkgHdr.Length;
>  FreePool (Package->IfrData);
>  FreePool (Package);
> -
> +//
> +// If Hii runtime support feature is enabled,
> +// will export Hii info for runtime use after ReadyToBoot event 
> triggered.
> +// If some driver add/update/remove packages from HiiDatabase 
> + after
> ReadyToBoot,
> +// will need to export the content of HiiDatabase.
> +// But if form packages removed, also need to export the 
> + ConfigResp
> string
> +//
> +if (gExportAfterReadyToBoot) {
> +  gExportConfigResp = TRUE;
> +}
>}
> 
>return EFI_SUCCESS;
>  }
> 
> @@ -2484,10 +2494,20 @@ AddPackages (
>   NotifyType,
>   (VOID *) FormPackage,
>   (UINT8) (PackageHeader.Type),
>   DatabaseRecord->Handle
>   );
> +  //
> +  // If Hii runtime support feature is enabled,
> +  // will export Hii info for runtime use after ReadyToBoot event 
> triggered.
> +  // If some driver add/update/remove packages from HiiDatabase 
> + after
> ReadyToBoot,
> +  // will need to export the content of HiiDatabase.
> +  // But if form packages added/updated, also need to export the
> ConfigResp string.
> +  //
> +  if (gExportAfterReadyToBoot) {
> +gExportConfigResp = TRUE;
> +  }
>break;
>  case EFI_HII_PACKAGE_KEYBOARD_LAYOUT:
>Status = InsertKeyboardLayoutPackage (
>   PackageHdrPtr,
>   NotifyType,
> @@ -2779,20 +2799,20 @@ ExportPackageList (
> 
>return EFI_SUCCESS;
>  }
> 
>  /**
> -This is an internal function,mainly use to get and update 
> configuration settings information.
> +This function mainly use to get and update ConfigResp string.
> 
>  @param  This   A pointer to the EFI_HII_DATABASE_PROTOCOL
> instance.
> 
>  @retval EFI_SUCCESSGet the information successfully.
>  @retval EFI_OUT_OF_RESOURCES   Not enough memory to store the
> Configuration Setting data.
> 
>  **/
>  EFI_STATUS
> -HiiGetConfigurationSetting(
> +HiiGetConfigRespInfo(
>IN CONST EFI_HII_DATABASE_PROTOCOL*This
>)
>  {
>EFI_STATUS  Status;
>HII_DATABASE_PRIVATE_DATA   *Private;
> @@ -2803,15 +2823,10 @@ HiiGetConfigurationSetting(
>ConfigSize   = 0;
> 
>Private = HII_DATABASE_DATABASE_PRIVATE_DATA_FROM_THIS (This);
> 
>//
> -  // Get the HiiDatabase info.
> -  //
> -  

Re: [edk2] [PATCH v1] MdePkg:Http11.h: Add defines for "Expect" header

[Fu, Siyuan]

Already committed 2c1c50fc61132517e352862b6748c57c5d443837

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hegde, 
Nagaraj P
Sent: Wednesday, April 27, 2016 11:08 AM
To: Wu, Jiaxin ; edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan 
Subject: Re: [edk2] [PATCH v1] MdePkg:Http11.h: Add defines for "Expect" header

Hi Jiaxin, Siyuan,

Can you please help me with the commit of this patch?

Regards,
Nagaraj.

-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Wednesday, April 27, 2016 6:48 AM
To: Hegde, Nagaraj P >; 
edk2-devel@lists.01.org
Cc: Fu, Siyuan >; Ye, Ting 
>; El-Haj-Mahmoud, Samer 
>
Subject: RE: [PATCH v1] MdePkg:Http11.h: Add defines for "Expect" header

Reviewed-by: Jiaxin Wu >


> -Original Message-
> From: Nagaraj Hegde [mailto:nagaraj-p.he...@hpe.com]
> Sent: Tuesday, April 26, 2016 11:47 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin >; Fu, Siyuan
> >; Ye, Ting 
> >;
> samer.el-haj-mahm...@hpe.com
> Subject: [PATCH v1] MdePkg:Http11.h: Add defines for "Expect" header
>
> Add #defines for "Expect" header, which is a part of RFC 2616 and used
> for HTTP PUT/POST operations.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hegde, Nagaraj P 
> >
> ---
>  MdePkg/Include/IndustryStandard/Http11.h | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/MdePkg/Include/IndustryStandard/Http11.h
> b/MdePkg/Include/IndustryStandard/Http11.h
> index 8a09f96..f735430 100644
> --- a/MdePkg/Include/IndustryStandard/Http11.h
> +++ b/MdePkg/Include/IndustryStandard/Http11.h
> @@ -234,6 +234,19 @@
>  /// Example: X-Auth-Token: 24de6b1f8fa147ad59f6452def628798
>  ///
>  #define  HTTP_HEADER_X_AUTH_TOKEN  "X-Auth-Token"
> +///
> +/// Expect Header
> +/// The "Expect" header field in a request indicates a certain set of
> +/// behaviors (expectations) that need to be supported by the server
> +in /// order to properly handle this request. The only such
> +expectation /// defined by this specification is 100-continue.
> +///
> +#define  HTTP_HEADER_EXPECT"Expect"
> +
> +///
> +/// Expect Header Value
> +///
> +#define  HTTP_EXPECT_100_CONTINUE   "100-continue"
>
>  #pragma pack()
>
> --
> 2.6.2.windows.1

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

Re: [edk2] [PATCH v1] MdePkg:Http11.h: Add defines for "Expect" header

[Hegde, Nagaraj P]

Hi Jiaxin, Siyuan,

Can you please help me with the commit of this patch?

Regards,
Nagaraj.

-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
Sent: Wednesday, April 27, 2016 6:48 AM
To: Hegde, Nagaraj P ; edk2-devel@lists.01.org
Cc: Fu, Siyuan ; Ye, Ting ; 
El-Haj-Mahmoud, Samer 
Subject: RE: [PATCH v1] MdePkg:Http11.h: Add defines for "Expect" header

Reviewed-by: Jiaxin Wu 


> -Original Message-
> From: Nagaraj Hegde [mailto:nagaraj-p.he...@hpe.com]
> Sent: Tuesday, April 26, 2016 11:47 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; Fu, Siyuan 
> ; Ye, Ting ; 
> samer.el-haj-mahm...@hpe.com
> Subject: [PATCH v1] MdePkg:Http11.h: Add defines for "Expect" header
> 
> Add #defines for "Expect" header, which is a part of RFC 2616 and used 
> for HTTP PUT/POST operations.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hegde, Nagaraj P 
> ---
>  MdePkg/Include/IndustryStandard/Http11.h | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Http11.h
> b/MdePkg/Include/IndustryStandard/Http11.h
> index 8a09f96..f735430 100644
> --- a/MdePkg/Include/IndustryStandard/Http11.h
> +++ b/MdePkg/Include/IndustryStandard/Http11.h
> @@ -234,6 +234,19 @@
>  /// Example: X-Auth-Token: 24de6b1f8fa147ad59f6452def628798
>  ///
>  #define  HTTP_HEADER_X_AUTH_TOKEN  "X-Auth-Token"
> +///
> +/// Expect Header
> +/// The "Expect" header field in a request indicates a certain set of 
> +/// behaviors (expectations) that need to be supported by the server 
> +in /// order to properly handle this request. The only such 
> +expectation /// defined by this specification is 100-continue.
> +///
> +#define  HTTP_HEADER_EXPECT"Expect"
> +
> +///
> +/// Expect Header Value
> +///
> +#define  HTTP_EXPECT_100_CONTINUE   "100-continue"
> 
>  #pragma pack()
> 
> --
> 2.6.2.windows.1

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

Re: [edk2] [Patch] NetworkPkg: Avoid the indefinite wait case in HttpDxe

[Hegde, Nagaraj P]

Reviewed-by: Hegde Nagaraj P 

-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com] 
Sent: Tuesday, April 26, 2016 4:09 PM
To: edk2-devel@lists.01.org
Cc: Hegde, Nagaraj P ; El-Haj-Mahmoud, Samer 
; Ye Ting ; Fu Siyuan 
; Zhang Lubo 
Subject: [Patch] NetworkPkg: Avoid the indefinite wait case in HttpDxe

Need the timer check to avoid the indefinite wait case in HttpDxe driver A.HTTP 
receive Header process in HttpTcpReceiveHeader(); B.HTTP receive Body process 
in HttpTcpReceiveBody();

Cc: Hegde Nagaraj P 
Cc: El-Haj-Mahmoud Samer 
Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Zhang Lubo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/HttpDxe/HttpImpl.c  | 60 --
 NetworkPkg/HttpDxe/HttpProto.c | 59 ++---
 NetworkPkg/HttpDxe/HttpProto.h | 15 +++
 3 files changed, 117 insertions(+), 17 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c 
index 63b683e..fe2acbc 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -174,10 +174,11 @@ EfiHttpConfigure (
 >IPv4Node,
 HttpConfigData->AccessPoint.IPv4Node,
 sizeof (HttpInstance->IPv4Node)
 );
 }
+
 //
 // Creat Tcp child
 //
 Status = HttpInitProtocol (HttpInstance, HttpInstance->LocalAddressIsIPv6);
 if (EFI_ERROR (Status)) {
@@ -894,11 +895,39 @@ HttpResponseWorker (
 }   
 
 HttpInstance->EndofHeader = 
 HttpInstance->HttpHeaders = 
 
-Status = HttpTcpReceiveHeader (HttpInstance, , );
+
+if (HttpInstance->TimeoutEvent == NULL) {
+  //
+  // Create TimeoutEvent for response
+  //
+  Status = gBS->CreateEvent (
+  EVT_TIMER,
+  TPL_CALLBACK,
+  NULL,
+  NULL,
+  >TimeoutEvent
+  );
+  if (EFI_ERROR (Status)) {
+goto Error;
+  }
+}
+
+//
+// Start the timer, and wait Timeout seconds to receive the header packet.
+//
+Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative, 
HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
+if (EFI_ERROR (Status)) {
+  goto Error;
+}
+
+Status = HttpTcpReceiveHeader (HttpInstance, , 
+ , HttpInstance->TimeoutEvent);
+
+gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
+
 if (EFI_ERROR (Status)) {
   goto Error;
 }
 
 ASSERT (HttpHeaders != NULL);
@@ -1095,14 +1124,41 @@ HttpResponseWorker (
 }
   }
 
   ASSERT (HttpInstance->MsgParser != NULL);
 
+  if (HttpInstance->TimeoutEvent == NULL) {
+//
+// Create TimeoutEvent for response
+//
+Status = gBS->CreateEvent (
+EVT_TIMER,
+TPL_CALLBACK,
+NULL,
+NULL,
+>TimeoutEvent
+);
+if (EFI_ERROR (Status)) {
+  goto Error;
+}
+  }
+
+  //
+  // Start the timer, and wait Timeout seconds to receive the body packet.
+  //
+  Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative, 
+ HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);  if (EFI_ERROR (Status)) {
+goto Error;
+  }
+
   //
   // We still need receive more data when there is no cache data and MsgParser 
is not NULL;
   //
-  Status = HttpTcpReceiveBody (Wrap, HttpMsg);
+  Status = HttpTcpReceiveBody (Wrap, HttpMsg, 
+ HttpInstance->TimeoutEvent);
+
+  gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
+
   if (EFI_ERROR (Status)) {
 goto Error;
   }
 
   return Status;
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c 
index 156f138..eb2af7f 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -813,10 +813,15 @@ HttpCleanProtocol (  {
   HttpCloseConnection (HttpInstance);
   
   HttpCloseTcpConnCloseEvent (HttpInstance);
 
+  if (HttpInstance->TimeoutEvent != NULL) {
+gBS->CloseEvent (HttpInstance->TimeoutEvent);
+HttpInstance->TimeoutEvent = NULL;
+  }
+
   if (HttpInstance->CacheBody != NULL) {
 FreePool (HttpInstance->CacheBody);
 HttpInstance->CacheBody = NULL;
 HttpInstance->NextMsg   = NULL;
   }
@@ -1537,20 +1542,22 @@ HttpTcpReceive (
   Receive the HTTP header by processing the associated HTTP token.
 
   @param[in]   HttpInstance The HTTP instance private data.
   @param[in, out]  SizeofHeadersThe HTTP header length.
   @param[in, out]  BufferSize   The size of buffer to cacahe the header 
message.
+  @param[in]   Timeout  The time to wait for receiving the header 
packet.

Re: [edk2] [PATCH v2] MdeModulePkg: Export ConfigResp only for form Package after ReadyToBoot

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Bi, Dandan
> Sent: Tuesday, April 26, 2016 11:03 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming; Dong, Eric
> Subject: [PATCH v2] MdeModulePkg: Export ConfigResp only for form
> Package after ReadyToBoot
> 
> The Hii runtime support feature will export the content of
> HiiDatabase and the ConfigResp string to runtime buffer
> after ReadyToBoot event is triggered. If some drivers
> add/update/remove packages from Hiidatabase after ReadyToBoot:
> Originally we will both export the content of HiiDatabase and
> the ConfigResp string for all packages.
> But now after investigation, we found only for form packages need
> to export the content of HiiDatabase and the ConfigResp string,
> for other packages just need to export the content of HiiDatabase.
> Now to enhance this logic.
> 
> Notes:
>   v1->v2:
>   - Modify the subject.
>   - Close the ReadyToBoot event.
>   - Add the check (whether need to export ConfigResp) in
> HiiGetConfigurationSetting(),
> doesn't update the caller logic.
> 
> Cc: Liming Gao 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> Reviewed-by: Eric Dong 
> ---
>  MdeModulePkg/Universal/HiiDatabaseDxe/Database.c   | 64
> +++---
>  .../Universal/HiiDatabaseDxe/HiiDatabaseEntry.c|  2 +
>  2 files changed, 58 insertions(+), 8 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> b/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> index def1eb7..d1eb881 100644
> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> @@ -17,10 +17,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
> 
>  EFI_HII_PACKAGE_LIST_HEADER*gRTDatabaseInfoBuffer = NULL;
>  EFI_STRING gRTConfigRespBuffer= NULL;
>  UINTN  gDatabaseInfoSize = 0;
>  UINTN  gConfigRespSize = 0;
> +BOOLEANgExportConfigResp = TRUE;
> 
>  /**
>This function generates a HII_DATABASE_RECORD node and adds into hii
> database.
>This is a internal function.
> 
> @@ -737,11 +738,20 @@ RemoveFormPackages (
> 
>  RemoveEntryList (>IfrEntry);
>  PackageList->PackageListHdr.PackageLength -= Package-
> >FormPkgHdr.Length;
>  FreePool (Package->IfrData);
>  FreePool (Package);
> -
> +//
> +// If Hii runtime support feature is enabled,
> +// will export Hii info for runtime use after ReadyToBoot event 
> triggered.
> +// If some driver add/update/remove packages from HiiDatabase after
> ReadyToBoot,
> +// will need to export the content of HiiDatabase.
> +// But if form packages removed, also need to export the ConfigResp
> string
> +//
> +if (gExportAfterReadyToBoot) {
> +  gExportConfigResp = TRUE;
> +}
>}
> 
>return EFI_SUCCESS;
>  }
> 
> @@ -2484,10 +2494,20 @@ AddPackages (
>   NotifyType,
>   (VOID *) FormPackage,
>   (UINT8) (PackageHeader.Type),
>   DatabaseRecord->Handle
>   );
> +  //
> +  // If Hii runtime support feature is enabled,
> +  // will export Hii info for runtime use after ReadyToBoot event 
> triggered.
> +  // If some driver add/update/remove packages from HiiDatabase after
> ReadyToBoot,
> +  // will need to export the content of HiiDatabase.
> +  // But if form packages added/updated, also need to export the
> ConfigResp string.
> +  //
> +  if (gExportAfterReadyToBoot) {
> +gExportConfigResp = TRUE;
> +  }
>break;
>  case EFI_HII_PACKAGE_KEYBOARD_LAYOUT:
>Status = InsertKeyboardLayoutPackage (
>   PackageHdrPtr,
>   NotifyType,
> @@ -2779,20 +2799,20 @@ ExportPackageList (
> 
>return EFI_SUCCESS;
>  }
> 
>  /**
> -This is an internal function,mainly use to get and update configuration
> settings information.
> +This function mainly use to get and update ConfigResp string.
> 
>  @param  This   A pointer to the EFI_HII_DATABASE_PROTOCOL
> instance.
> 
>  @retval EFI_SUCCESSGet the information successfully.
>  @retval EFI_OUT_OF_RESOURCES   Not enough memory to store the
> Configuration Setting data.
> 
>  **/
>  EFI_STATUS
> -HiiGetConfigurationSetting(
> +HiiGetConfigRespInfo(
>IN CONST EFI_HII_DATABASE_PROTOCOL*This
>)
>  {
>EFI_STATUS  Status;
>HII_DATABASE_PRIVATE_DATA   *Private;
> @@ -2803,15 +2823,10 @@ HiiGetConfigurationSetting(
>ConfigSize   = 0;
> 
>Private = HII_DATABASE_DATABASE_PRIVATE_DATA_FROM_THIS (This);
> 
>//
> -  // Get the HiiDatabase info.
> -  //
> -  HiiGetDatabaseInfo(This);
> -
> -  //
>  

Re: [edk2] [PATCH v1 1/2] MdeModulePkg:DxeHttpLib: Update to DxeHttpLib API

[Fu, Siyuan]

Hi, Nagaraj

I suggest to add more API descriptions to the modified interface, will add 
below words when commit the patch. Other parts are good to me.

Reviewed-by: Fu Siyuan 

/**
  Generate HTTP request message.

  This function will allocate memory for the whole HTTP message and generate a
  well formatted HTTP Request message in it, include the Request-Line, header
  fields and also the message body. It is the caller's responsibility to free
  the buffer returned in *RequestMsg.
  
  ...


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Nagaraj Hegde
> Sent: Monday, April 4, 2016 6:09 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH v1 1/2] MdeModulePkg:DxeHttpLib: Update to
> DxeHttpLib API
> 
> Rename and update the logic of HttpGenRequestString API provided
> by DxeHttpLib. The RequestString size is returned as an argument.
> The user is not expected to do a AsciiStrLen anymore, and is not
> logical too, since request string can contain message body and
> using AsciiStrLen on such a string can provide truncated lengths.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Nagaraj Hegde 
> ---
>  MdeModulePkg/Include/Library/HttpLib.h   | 10 +++---
>  MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c | 34 +---
>  2 files changed, 28 insertions(+), 16 deletions(-)
> 
> diff --git a/MdeModulePkg/Include/Library/HttpLib.h
> b/MdeModulePkg/Include/Library/HttpLib.h
> index af9ab5f..d8424ad 100644
> --- a/MdeModulePkg/Include/Library/HttpLib.h
> +++ b/MdeModulePkg/Include/Library/HttpLib.h
> @@ -417,12 +417,13 @@ HttpFreeHeaderFields (
>);
> 
>  /**
> -  Generate HTTP request string.
> +  Generate HTTP request message.
> 
>@param[in]   MessagePointer to storage containing HTTP message
> data.
>@param[in]   UrlThe URL of a remote host.
> -  @param[out]  RequestString  Pointer to the created HTTP request string.
> +  @param[out]  RequestMsg Pointer to the created HTTP request
> message.
>NULL if any error occured.
> +  @param[out]  RequestMsgSize Size of the RequestMsg (in bytes).
> 
>@return EFI_SUCCESS If HTTP request string was created 
> successfully
>@retval EFI_OUT_OF_RESOURCESFailed to allocate resources.
> @@ -431,10 +432,11 @@ HttpFreeHeaderFields (
>  **/
>  EFI_STATUS
>  EFIAPI
> -HttpGenRequestString (
> +HttpGenRequestMessage (
>IN CONST EFI_HTTP_MESSAGE*Message,
>IN CONST CHAR8   *Url,
> - OUT CHAR8 **RequestString
> + OUT CHAR8 **RequestMsg,
> + OUT UINTN *RequestMsgSize
>);
> 
>  /**
> diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> index 662c40c..cdbb0c7 100644
> --- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> +++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> @@ -1630,12 +1630,13 @@ HttpFreeHeaderFields (
>  }
> 
>  /**
> -  Generate HTTP request string.
> +  Generate HTTP request message.
> 
>@param[in]   MessagePointer to storage containing HTTP message
> data.
>@param[in]   UrlThe URL of a remote host.
> -  @param[out]  RequestString  Pointer to the created HTTP request string.
> +  @param[out]  RequestMsg Pointer to the created HTTP request
> message.
>NULL if any error occured.
> +  @param[out]  RequestMsgSize Size of the RequestMsg (in bytes).
> 
>@return EFI_SUCCESS If HTTP request string was created 
> successfully
>@retval EFI_OUT_OF_RESOURCESFailed to allocate resources.
> @@ -1644,10 +1645,11 @@ HttpFreeHeaderFields (
>  **/
>  EFI_STATUS
>  EFIAPI
> -HttpGenRequestString (
> +HttpGenRequestMessage (
>IN CONST EFI_HTTP_MESSAGE*Message,
>IN CONST CHAR8   *Url,
> - OUT CHAR8 **Request
> + OUT CHAR8 **RequestMsg,
> + OUT UINTN *RequestMsgSize
>)
>  {
>EFI_STATUS   Status;
> @@ -1664,7 +1666,7 @@ HttpGenRequestString (
> 
>ASSERT (Message != NULL);
> 
> -  *Request = NULL;
> +  *RequestMsg = NULL;
>MsgSize = 0;
>Success = FALSE;
>HttpHdr = NULL;
> @@ -1727,13 +1729,13 @@ HttpGenRequestString (
>  AsciiStrLen (HTTP_VERSION_CRLF_STR) + HttpHdrSize;
> 
> 
> -  *Request = AllocateZeroPool (MsgSize);
> -  if (*Request == NULL) {
> +  *RequestMsg = AllocateZeroPool (MsgSize);
> +  if (*RequestMsg == NULL) {
>  Status = EFI_OUT_OF_RESOURCES;
>  goto Exit;
>}
> 
> -  RequestPtr = *Request;
> +  RequestPtr = *RequestMsg;
>//
>// Construct header request
>//
> @@ -1793,18 +1795,26 @@ HttpGenRequestString (
>RequestPtr += 

Re: [edk2] [PATCH v1 2/2] NetworkPkg:HttpDxe:Consume DxeHttpLib API changes

[Fu, Siyuan]

Reviewed-by: Fu Siyuan 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Nagaraj Hegde
> Sent: Monday, April 4, 2016 6:09 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH v1 2/2] NetworkPkg:HttpDxe:Consume DxeHttpLib API
> changes
> 
> HttpGenRequestString is updated to HttpGenRequestMessage,
> with an additional argument. This patch updates the caller
> of the DxeHttpLib API. Also, we will avoid adding any '\0'
> to the string, which was added to make AsciiStrLen to
> work on the string.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Nagaraj Hegde 
> ---
>  NetworkPkg/HttpDxe/HttpImpl.c   | 15 ---
>  NetworkPkg/HttpDxe/HttpProto.c  | 14 --
>  NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesProtocol.c |  9 +
>  3 files changed, 17 insertions(+), 21 deletions(-)
> 
> diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c
> index 63b683e..eb44b09 100644
> --- a/NetworkPkg/HttpDxe/HttpImpl.c
> +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> @@ -240,12 +240,13 @@ EfiHttpRequest (
>HTTP_PROTOCOL *HttpInstance;
>BOOLEAN   Configure;
>BOOLEAN   ReConfigure;
> -  CHAR8 *RequestStr;
> +  CHAR8 *RequestMsg;
>CHAR8 *Url;
>UINTN UrlLen;
>CHAR16*HostNameStr;
>HTTP_TOKEN_WRAP   *Wrap;
>CHAR8 *FileUrl;
> +  UINTN RequestMsgSize;
> 
>if ((This == NULL) || (Token == NULL)) {
>  return EFI_INVALID_PARAMETER;
> @@ -314,7 +315,7 @@ EfiHttpRequest (
>  goto Error1;
>}
> 
> -  RequestStr = NULL;
> +  RequestMsg = NULL;
>HostName   = NULL;
>Status = HttpUrlGetHostName (Url, UrlParser, );
>if (EFI_ERROR (Status)) {
> @@ -498,7 +499,7 @@ EfiHttpRequest (
>  }
>}
> 
> -  Status = HttpGenRequestString (HttpMsg, FileUrl, );
> +  Status = HttpGenRequestMessage (HttpMsg, FileUrl, ,
> );
> 
>if (EFI_ERROR (Status)) {
>  goto Error3;
> @@ -515,8 +516,8 @@ EfiHttpRequest (
>Status = HttpTransmitTcp (
>   HttpInstance,
>   Wrap,
> - (UINT8*) RequestStr,
> - AsciiStrLen (RequestStr)
> + (UINT8*) RequestMsg,
> + RequestMsgSize
>   );
>if (EFI_ERROR (Status)) {
>  goto Error5;
> @@ -534,8 +535,8 @@ Error5:
>  NetMapRemoveTail (>TxTokens, NULL);
> 
>  Error4:
> -  if (RequestStr != NULL) {
> -FreePool (RequestStr);
> +  if (RequestMsg != NULL) {
> +FreePool (RequestMsg);
>}
> 
>  Error3:
> diff --git a/NetworkPkg/HttpDxe/HttpProto.c
> b/NetworkPkg/HttpDxe/HttpProto.c
> index 156f138..8b0c894 100644
> --- a/NetworkPkg/HttpDxe/HttpProto.c
> +++ b/NetworkPkg/HttpDxe/HttpProto.c
> @@ -1462,8 +1462,9 @@ HttpTcpTransmit (
>  {
>HTTP_TOKEN_WRAP   *ValueInItem;
>EFI_STATUSStatus;
> -  CHAR8 *RequestStr;
> +  CHAR8 *RequestMsg;
>CHAR8 *Url;
> +  UINTN RequestMsgSize;
> 
>ValueInItem = (HTTP_TOKEN_WRAP *) Item->Value;
>if (ValueInItem->TcpWrap.IsTxDone) {
> @@ -1483,10 +1484,11 @@ HttpTcpTransmit (
>//
>// Create request message.
>//
> -  Status = HttpGenRequestString (
> +  Status = HttpGenRequestMessage (
>   ValueInItem->HttpToken->Message,
>   Url,
> - 
> + ,
> + 
>   );
>FreePool (Url);
> 
> @@ -1500,10 +1502,10 @@ HttpTcpTransmit (
>Status = HttpTransmitTcp (
>   ValueInItem->HttpInstance,
>   ValueInItem,
> - (UINT8*) RequestStr,
> - AsciiStrLen (RequestStr)
> + (UINT8*) RequestMsg,
> + RequestMsgSize
>   );
> -  FreePool (RequestStr);
> +  FreePool (RequestMsg);
>return Status;
>  }
> 
> diff --git a/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesProtocol.c
> b/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesProtocol.c
> index 739d3b7..79001de 100644
> --- a/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesProtocol.c
> +++ b/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesProtocol.c
> @@ -207,11 +207,6 @@ HttpUtilitiesBuild (
>StrLength = sizeof("\r\n") - 1;
>*NewMessageSize += StrLength;
> 
> -  //
> -  // Final 0 for end flag
> -  //
> -  *NewMessageSize += 1;
> -
>*NewMessage = AllocateZeroPool (*NewMessageSize);
>if (*NewMessage == NULL) {
>  Status = EFI_OUT_OF_RESOURCES;
> @@ -243,9 +238,7 @@ HttpUtilitiesBuild (
>CopyMem (NewMessagePtr, "\r\n", StrLength);
>NewMessagePtr += StrLength;
> 
> -  *NewMessagePtr = 0;
> -
> -  ASSERT (*NewMessageSize == (UINTN)NewMessagePtr -
> 

[edk2] [PATCH] Vlv2TbltDevicePkg: Modify DSC file to ensure PlatformPkgIA32.dsc is sync with PlatformPkgX64.dsc.

[Guo, Mang]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Mang Guo 
Reviewed-by: David Wei 
---
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 11 ++-
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc  |  5 +++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
index cb0aae3..70ff2e0 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
@@ -1125,7 +1125,16 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
 !endif
   }
 
-
+!if $(DXE_ARCHITECTURE) == X64
+!if $(CAPSULE_ENABLE) == TRUE
+  MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf {
+
+PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
+HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
+  }
+!endif
+!endif
 
   
MdeModulePkg/Universal/ReportStatusCodeRouter/Smm/ReportStatusCodeRouterSmm.inf
   MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf{
diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
index 3432a13..a031208 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
@@ -1125,7 +1125,8 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
   DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
 !endif
   }
-
+  
+!if $(DXE_ARCHITECTURE) == X64
 !if $(CAPSULE_ENABLE) == TRUE
   MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf {
 
@@ -1134,6 +1135,7 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
 HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
   }
 !endif
+!endif
 
   
MdeModulePkg/Universal/ReportStatusCodeRouter/Smm/ReportStatusCodeRouterSmm.inf
   MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf{
@@ -1201,7 +1203,6 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
   !if $(ESRT_ENABLE) == TRUE
   
CapsuleLib|$(PLATFORM_PACKAGE)/Library/DxeEsrtCapsuleRtLib/DxeEsrtCapsuleRtLib.inf
   !endif
-  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
   }
 
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
-- 
2.8.1.windows.1

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

Re: [edk2] [Patch v3 00/23] Use MdeModulePkg/BDS in OVMF platform

[Andrew Fish]

> On Apr 26, 2016, at 8:58 AM, Laszlo Ersek  wrote:
> 
> On 04/26/16 17:38, Michael Zimmermann wrote:
>> is Intel's bds deprecated now
> 
> Yes, it is. I seem to remember that Ray said he wouldn't implement new
> UEFI spec features for the BDS driver in IntelFrameworkModulePkg, only
> the new one in MdeModulePkg.
> 
> IIRC the main reason for the new BDS driver (in MdeModulePkg) is better
> separation of responsibilities -- there is now a BDS driver providing
> the BDS arch protocol, and a standalone UEFI application that is
> responsible for UI etc. As far as I recall anyway.
> 

The IntelFrameworkModulePkg/IntelFrameworkPkg use definitions from the Intel(r) 
Platform Innovation Framework for EFI set of specifications, and I don't think 
those specs have been updated since 2004-2005 ish? Most of that functionality 
was moved over to the UEFI Forum owned Platform Initialization (PI) 
specification. The MdePkg/MdeModulePkg support the industry standards and the 
UEFI Forum specifications. So it makes sense the Intel Framework stuff is 
hitting end of support. 

Thanks,

Andrew Fish 

> Thanks
> Laszlo
> 
>> or what is this switch about?
>> 
>> Michael
>> 
>> On Thu, Apr 21, 2016 at 9:03 AM, Ni, Ruiyu  wrote:
>> 
>>> The changes set can be found in below GIT repos:
>>> https://github.com/niruiyu/edk2/tree/Ovmf_Bds2
>>> 
>>> 
>>> Regards,
>>> Ray
>>> 
 -Original Message-
 From: Ni, Ruiyu
 Sent: Thursday, April 21, 2016 2:58 PM
 To: edk2-devel@lists.01.org
 Cc: Ni, Ruiyu 
 Subject: [Patch v3 00/23] Use MdeModulePkg/BDS in OVMF platform
 
 The patch serials creates a flag USE_OLD_BDS and by default the value
 of the flag is FALSE so that the new MdeModulePkg/BDS is used.
 User can define USE_OLD_BDS as TRUE to force to use
>>> IntelFrameworkModulePkg
 /BDS.
 
 The v3 adopts comments for v1 and v2 to split the big changes to
 small changes and also expose the EfiBootManagerGetLoadOptionBuffer().
 
 Ruiyu Ni (23):
 MdeModulePkg/UefiBootManagerLib: Expose *GetLoadOptionBuffer() API
 OvmfPkg/PlatformPei: Add memory above 4GB as tested
 OvmfPkg: Duplicate QemuBootOrderLib to QemuNewBootOrderLib
 OvmfPkg/QemuNewBootOrderLib: Build with UefiBootManagerLib
 OvmfPkg: Duplicate PlatformBdsLib to PlatformBootManagerLib
 OvmfPkg/PlatformBds: Rename INF file
 OvmfPkg/PlatformBds: Follow PlatformBootManagerLib interfaces
 OvmfPkg/PlatformBds: use EfiBootManagerUpdateConsoleVariable
 OvmfPkg/PlatformBds: link to UefiBootManagerLib
 OvmfPkg/PlatformBds: Use ConvertDevicePathToText in DevicePathLib
 OvmfPkg/PlatformBds: Initialize console variables in *BeforeConsole()
 OvmfPkg/PlatformBds: Do not launch Boot Manager Menu
 OvmfPkg/PlatformBds: Register boot options and hot keys.
 OvmfPkg/PlatformBds: Remove unused local functions.
 OvmfPkg/PlatformBds: Change PlatformBdsConnectSequence()
 OvmfPkg/PlatformBds: Use EfiBootManagerRefreshAllBootOption()
 OvmfPkg/PlatformBds: Remove PlatformBdsGetDriverOption()
 OvmfPkg/PlatformBds: Use GetBootModeHob() in HobLib
 OvmfPkg/PlatformBds: Remove unnecessary memory test
 OvmfPkg/PlatformBds: Remove unused variables and function prototypes.
 OvmfPkg/PlatformBds: Add EnableQuietBoot and DisableQuietBoot
 OvmfPkg/PlatformBds: Remove unused C structures definitions.
 OvmfPkg: Use MdeModulePkg/BDS
 
 MdeModulePkg/Include/Library/UefiBootManagerLib.h  |   23 +-
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |   11 +-
 .../Library/UefiBootManagerLib/BmLoadOption.c  |2 +-
 .../Library/UefiBootManagerLib/InternalBm.h|   19 -
 .../Library/PlatformBootManagerLib/BdsPlatform.c   | 1371 ++
 .../Library/PlatformBootManagerLib/BdsPlatform.h   |  246 +++
 .../PlatformBootManagerLib.inf |   80 +
 .../Library/PlatformBootManagerLib/PlatformData.c  |   41 +
 .../Library/PlatformBootManagerLib/QemuKernel.c|  170 ++
 OvmfPkg/Library/PlatformBootManagerLib/QuietBoot.c |  668 +++
 .../Library/QemuNewBootOrderLib/ExtraRootBusMap.c  |  313 
 .../Library/QemuNewBootOrderLib/ExtraRootBusMap.h  |   40 +
 .../Library/QemuNewBootOrderLib/QemuBootOrderLib.c | 1913
>>> 
 .../QemuNewBootOrderLib/QemuBootOrderLib.inf   |   68 +
 OvmfPkg/OvmfPkgIa32.dsc|   45 +-
 OvmfPkg/OvmfPkgIa32.fdf|5 +
 OvmfPkg/OvmfPkgIa32X64.dsc |   47 +-
 OvmfPkg/OvmfPkgIa32X64.fdf |5 +
 OvmfPkg/OvmfPkgX64.dsc |   45 +-
 OvmfPkg/OvmfPkgX64.fdf |5 +
 OvmfPkg/PlatformPei/MemDetect.c|4 +-
 OvmfPkg/PlatformPei/Platform.c |   29 -
 

[edk2] [patch 2/2] MdeModulePkg/SetupBrowser: Call submit callback function when no failure

[Dandan Bi]

In current code will always call submit callback function,
but we should call submit callback function when has no failure
in the submit action. This patch to fix this issues.

Cc: Liming Gao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 

---
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/SetupBrowserDxe/Setup.c 
b/MdeModulePkg/Universal/SetupBrowserDxe/Setup.c
index a437674..23094f8 100644
--- a/MdeModulePkg/Universal/SetupBrowserDxe/Setup.c
+++ b/MdeModulePkg/Universal/SetupBrowserDxe/Setup.c
@@ -3180,10 +3180,13 @@ SubmitForForm (
   LIST_ENTRY  *Link;
   EFI_STRING  ConfigResp;
   EFI_STRING  Progress;
   BROWSER_STORAGE *Storage;
   FORM_BROWSER_CONFIG_REQUEST  *ConfigInfo;
+  BOOLEAN SubmitFormFail;
+
+  SubmitFormFail = FALSE;
 
   if (!IsNvUpdateRequiredForForm (Form)) {
 return EFI_SUCCESS;
   }
 
@@ -3229,10 +3232,11 @@ SubmitForForm (
 
 if (EFI_ERROR (Status)) {
   //
   // Submit fail, to get the RestoreConfigRequest and SyncConfigRequest.
   //
+  SubmitFormFail = TRUE;
   GetSyncRestoreConfigRequest (ConfigInfo->Storage, 
ConfigInfo->ConfigRequest, Progress, >RestoreConfigRequest, 
>SyncConfigRequest);
   InsertTailList (, >SaveFailLink);
   continue;
 }
 
@@ -3286,11 +3290,13 @@ SubmitForForm (
   ValueChangeResetFlagUpdate(TRUE, FormSet, Form);
 
   //
   // 6 Call callback with Submitted type to inform the driver.
   //
-  SubmitCallback (FormSet, Form);
+  if (!SubmitFormFail) {
+SubmitCallback (FormSet, Form);
+  }
 
   return Status;
 }
 
 /**
@@ -3322,12 +3328,14 @@ SubmitForFormSet (
   BROWSER_STORAGE *Storage;
   FORMSET_STORAGE *FormSetStorage;
   FORM_BROWSER_FORM   *Form;
   BOOLEAN HasInserted;
   FORM_BROWSER_STATEMENT  *Question;
+  BOOLEAN SubmitFormSetFail;
 
   HasInserted = FALSE;
+  SubmitFormSetFail = FALSE;
 
   if (!IsNvUpdateRequiredForFormSet (FormSet)) {
 return EFI_SUCCESS;
   }
 
@@ -3386,10 +3394,11 @@ SubmitForFormSet (
   );
 if (EFI_ERROR (Status)) {
   //
   // Submit fail, to get the RestoreConfigRequest and SyncConfigRequest.
   //
+  SubmitFormSetFail = TRUE;
   GetSyncRestoreConfigRequest (FormSetStorage->BrowserStorage, 
FormSetStorage->ConfigRequest, Progress, >RestoreConfigRequest, 
>SyncConfigRequest);
   InsertTailList (>SaveFailStorageListHead, 
>SaveFailLink);
   if (!HasInserted) {
 //
 // Call submit formset for system level, save the formset info
@@ -3479,11 +3488,13 @@ SubmitForFormSet (
   ValueChangeResetFlagUpdate(TRUE, FormSet, NULL);
 
   //
   // 6. Call callback with Submitted type to inform the driver.
   //
-  SubmitCallback (FormSet, NULL);
+  if (!SubmitFormSetFail) {
+SubmitCallback (FormSet, NULL);
+  }
 
   return Status;
 }
 
 /**
-- 
1.9.5.msysgit.1

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

[edk2] [patch 1/2] MdeModulePkg: Restore question base on the fail info when submit fail

[Dandan Bi]

When RouteConfig function fail in SubmitForForm or SubmitForFormSet
function, we should restore the question value base on the failure
information, should not restore all the question.
This patch to fix this issue.

Cc: Liming Gao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 

---
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.c | 152 -
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.h |   6 +-
 2 files changed, 151 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Universal/SetupBrowserDxe/Setup.c 
b/MdeModulePkg/Universal/SetupBrowserDxe/Setup.c
index 5887e0f..a437674 100644
--- a/MdeModulePkg/Universal/SetupBrowserDxe/Setup.c
+++ b/MdeModulePkg/Universal/SetupBrowserDxe/Setup.c
@@ -2846,10 +2846,112 @@ FindQuestionFromProgress (
 
   return (BOOLEAN) (*RetForm != NULL);
 }
 
 /**
+  Base on the return Progress string to get the SyncConfigRequest and 
RestoreConfigRequest
+  for form and formset.
+
+  @param  Storage Storage which has this Progress string.
+  @param  ConfigRequest   The ConfigRequest string.
+  @param  ProgressThe Progress string which has the first fail 
string.
+  @param  RestoreConfigRequestReturn the RestoreConfigRequest string.
+  @param  SyncConfigRequest   Return the SyncConfigRequest string.
+
+**/
+VOID
+GetSyncRestoreConfigRequest(
+  IN  BROWSER_STORAGE   *Storage,
+  IN  EFI_STRINGConfigRequest,
+  IN  EFI_STRINGProgress,
+  OUT EFI_STRING*RestoreConfigRequest,
+  OUT EFI_STRING*SyncConfigRequest
+  )
+{
+  EFI_STRINGEndStr;
+  EFI_STRINGConfigHdrEndStr;
+  EFI_STRINGElementStr;
+  UINTN TotalSize;
+  UINTN RestoreEleSize;
+  UINTN SyncSize;
+
+  ASSERT ((*Progress == L'&') || (*Progress == L'G'));
+  //
+  // If the Progress starts with ConfigHdr, means the failure is in the first 
name / value pair.
+  // Need to restore all the fields in the ConfigRequest.
+  //
+  if (*Progress == L'G') {
+*RestoreConfigRequest = AllocateCopyPool (StrSize (ConfigRequest), 
ConfigRequest);
+ASSERT (*RestoreConfigRequest != NULL);
+return;
+  }
+
+  //
+  // Find the first fail "NAME" or "OFFSET=0x=0x" string.
+  //
+  if (Storage->Type == EFI_HII_VARSTORE_NAME_VALUE) {
+//
+// For Name/Value type, the data is "=16=16=12" formset,
+// here, just keep the "Fred" string.
+//
+EndStr = StrStr (Progress, L"=");
+ASSERT (EndStr != NULL);
+*EndStr = L'\0';
+//
+// Find the ConfigHdr in ConfigRequest.
+//
+ConfigHdrEndStr = StrStr (ConfigRequest, L"PATH=");
+ASSERT (ConfigHdrEndStr != NULL);
+while (*ConfigHdrEndStr != L'&') {
+  ConfigHdrEndStr++;
+}
+  } else {
+//
+// For Buffer type, the data is "OFFSET=0x=0x=0x",
+// here, just keep the "OFFSET=0x=0x" string.
+//
+EndStr = StrStr (Progress, L"=");
+ASSERT (EndStr != NULL);
+*EndStr = L'\0';
+//
+// Find the ConfigHdr in ConfigRequest.
+//
+ConfigHdrEndStr = StrStr (ConfigRequest, L"=");
+  }
+  //
+  // Find the first fail pair in the ConfigRequest.
+  //
+  ElementStr = StrStr (ConfigRequest, Progress);
+  ASSERT (ElementStr != NULL);
+  //
+  // To get the RestoreConfigRequest.
+  //
+  RestoreEleSize = StrSize (ElementStr);
+  TotalSize = (ConfigHdrEndStr - ConfigRequest) * sizeof (CHAR16) + 
RestoreEleSize + sizeof (CHAR16);
+  *RestoreConfigRequest = AllocateZeroPool (TotalSize);
+  ASSERT (*RestoreConfigRequest != NULL);
+  StrnCpyS (*RestoreConfigRequest, TotalSize / sizeof (CHAR16), ConfigRequest, 
ConfigHdrEndStr - ConfigRequest);
+  StrCatS (*RestoreConfigRequest, TotalSize / sizeof (CHAR16), ElementStr);
+  //
+  // To get the SyncConfigRequest.
+  //
+  SyncSize = StrSize (ConfigRequest) - RestoreEleSize + sizeof (CHAR16);
+  *SyncConfigRequest = AllocateZeroPool (SyncSize);
+  ASSERT (*SyncConfigRequest != NULL);
+  StrnCpyS (*SyncConfigRequest, SyncSize / sizeof (CHAR16), ConfigRequest, 
SyncSize / sizeof (CHAR16) - 1);
+
+  //
+  // restore the Progress string to the original format.
+  //
+  if (Storage->Type == EFI_HII_VARSTORE_NAME_VALUE) {
+*EndStr = L'=';
+  } else {
+*EndStr = L'&';
+  }
+}
+
+/**
   Popup an save error info and get user input.
 
   @param  TitleIdThe form title id.
   @param  HiiHandle  The hii handle for this package.
 
@@ -3124,10 +3226,14 @@ SubmitForForm (
   
   );
 FreePool (ConfigResp);
 
 if (EFI_ERROR (Status)) {
+  //
+  // Submit fail, to get the RestoreConfigRequest and SyncConfigRequest.
+  //
+  GetSyncRestoreConfigRequest (ConfigInfo->Storage, 
ConfigInfo->ConfigRequest, Progress, >RestoreConfigRequest, 

[edk2] [patch 0/2] MdeModulePkg/SetupBrowser: Fix two issues in submit form/formset

[Dandan Bi]

Patch 1 is to restore the question value base on the 
submit fail info when submit action failed.

Patch 2 is to call submit callback function only
when there are no failure in submit action.

Cc: Liming Gao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 

Dandan Bi (2):
  MdeModulePkg: Restore question base on the fail info when submit fail
  MdeModulePkg/SetupBrowser: Call submit callback function when no
failure

 MdeModulePkg/Universal/SetupBrowserDxe/Setup.c | 167 +++--
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.h |   6 +-
 2 files changed, 164 insertions(+), 9 deletions(-)

-- 
1.9.5.msysgit.1

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

Re: [edk2] [Patch] ShellPkg: Enhance ping6 to select the interface automatically

[Wu, Jiaxin]

Jaben and Bhupesh,

Any comments for this patch?

Thanks.
Jiaxin

> -Original Message-
> From: Wu, Jiaxin
> Sent: Friday, April 22, 2016 11:01 AM
> To: Bhupesh Sharma ; Wu, Jiaxin
> ; edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Ye, Ting ;
> Fu, Siyuan 
> Subject: RE: [edk2] [Patch] ShellPkg: Enhance ping6 to select the interface
> automatically
> 
> Hello Bhupesh,
> 
> Can you also help to verify the ping6 command for the same case as ping?
> 
> Thanks and Best Regards!
> Jiaxin
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Jiaxin Wu
> > Sent: Friday, April 22, 2016 10:57 AM
> > To: edk2-devel@lists.01.org
> > Cc: Carsey, Jaben ; Ye, Ting
> > ; Fu, Siyuan 
> > Subject: [edk2] [Patch] ShellPkg: Enhance ping6 to select the
> > interface automatically
> >
> > This patch is used to support no source IP specified case while
> > multiple NICs existed in the platform. The command will select the
> > first both connected and configured interface automatically.
> >
> > Cc: Bhupesh Sharma 
> > Cc: Jaben Carsey 
> > Cc: Ye Ting 
> > Cc: Fu Siyuan 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jiaxin Wu 
> > ---
> >  .../Library/UefiShellNetwork2CommandsLib/Ping6.c   | 166
> --
> > ---
> >  1 file changed, 95 insertions(+), 71 deletions(-)
> >
> > diff --git a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
> > b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
> > index af7d08f..f129612 100644
> > --- a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
> > +++ b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
> > @@ -661,22 +661,26 @@ Ping6CreateIpInstance (  {
> >EFI_STATUS   Status;
> >UINTNHandleIndex;
> >UINTNHandleNum;
> >EFI_HANDLE   *HandleBuffer;
> > +  BOOLEAN  UnspecifiedSrc;
> > +  BOOLEAN  MediaPresent;
> >EFI_SERVICE_BINDING_PROTOCOL *Ip6Sb;
> >EFI_IP6_CONFIG_PROTOCOL  *Ip6Cfg;
> >EFI_IP6_CONFIG_DATA  Ip6Config;
> >EFI_IP6_CONFIG_INTERFACE_INFO*IfInfo;
> >UINTNIfInfoSize;
> >EFI_IPv6_ADDRESS *Addr;
> >UINTNAddrIndex;
> >
> > -  HandleBuffer = NULL;
> > -  Ip6Sb= NULL;
> > -  IfInfo   = NULL;
> > -  IfInfoSize   = 0;
> > +  HandleBuffer  = NULL;
> > +  UnspecifiedSrc= FALSE;
> > +  MediaPresent  = TRUE;
> > +  Ip6Sb = NULL;
> > +  IfInfo= NULL;
> > +  IfInfoSize= 0;
> >
> >//
> >// Locate all the handles with ip6 service binding protocol.
> >//
> >Status = gBS->LocateHandleBuffer (
> > @@ -687,115 +691,135 @@ Ping6CreateIpInstance (
> >
> >);
> >if (EFI_ERROR (Status) || (HandleNum == 0)) {
> >  return EFI_ABORTED;
> >}
> > +
> > +  if (NetIp6IsUnspecifiedAddr (>SrcAddress)) {
> > +//
> > +// SrcAddress is unspecified. So, both connected and configured
> > + interface
> > will be automatic selected.
> > +//
> > +UnspecifiedSrc = TRUE;
> > +  }
> > +
> >//
> >// Source address is required when pinging a link-local address on multi-
> >// interfaces host.
> >//
> >if (NetIp6IsLinkLocalAddr (>DstAddress) &&
> > -  NetIp6IsUnspecifiedAddr (>SrcAddress) &&
> > -  (HandleNum > 1)) {
> > +  UnspecifiedSrc && (HandleNum > 1)) {
> >  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> > (STR_PING6_INVALID_SOURCE), gShellNetwork2HiiHandle);
> >  Status = EFI_INVALID_PARAMETER;
> >  goto ON_ERROR;
> >}
> > +
> >//
> >// For each ip6 protocol, check interface addresses list.
> >//
> >for (HandleIndex = 0; HandleIndex < HandleNum; HandleIndex++) {
> >
> >  Ip6Sb  = NULL;
> >  IfInfo = NULL;
> >  IfInfoSize = 0;
> >
> > +if (UnspecifiedSrc) {
> > +  //
> > +  // Check media.
> > +  //
> > +  NetLibDetectMedia (HandleBuffer[HandleIndex], );
> > +  if (!MediaPresent) {
> > +//
> > +// Skip this one.
> > +//
> > +continue;
> > +  }
> > +}
> > +
> >  Status = gBS->HandleProtocol (
> >  HandleBuffer[HandleIndex],
> >  ,
> >  (VOID **) 
> >  );
> >  if (EFI_ERROR (Status)) {
> >goto ON_ERROR;
> >  }
> >
> > -if (NetIp6IsUnspecifiedAddr (>SrcAddress)) {
> > -  //
> > -  // No need to match interface address.
> > -  //
> > -  

Re: [edk2] Question about SmmProfile logic

[Fan, Jeff]

Thanks your report. This is a bug.

We will send the patch to fix it soon. Moreover, PEBS feature is not required 
for SmmProfile and only BTS feature support is enough.

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Shifflett, Joseph
Sent: Wednesday, April 27, 2016 12:59 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Question about SmmProfile logic

I have a question about the logic of this code here:

https://svn.code.sf.net/p/edk2/code/trunk/edk2/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c

>From Line 958:

  if (mBtsSupported) {
AsmCpuid (CPUID_VERSION_INFO, NULL, NULL, NULL, );
if ((RegEdx & CPUID1_EDX_BTS_AVAILABLE) != 0) {
  //
  // Per IA32 manuals:
  // When CPUID.1:EDX[21] is set, the following BTS facilities are 
available:
  // 1. The BTS_UNAVAILABLE flag in the IA32_MISC_ENABLE MSR indicates the
  //availability of the BTS facilities, including the ability to set 
the BTS and
  //BTINT bits in the MSR_DEBUGCTLA MSR.
  // 2. The IA32_DS_AREA MSR can be programmed to point to the DS save area.
  //
  if ((AsmMsrBitFieldRead64 (MSR_IA32_MISC_ENABLE, 11, 11) == 0) &&
  (AsmMsrBitFieldRead64 (MSR_IA32_MISC_ENABLE, 12, 12) == 0)) {
//
// BTS facilities is supported.
//
mBtsSupported = FALSE;
  }
}
  }


According to Volume 3 of the Intel 64 and IA-32 Architectures Software 
Developer's Manual 
(http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf),
 bits 11 and 12 of MSR _01A0 indicate BTS and PEBS are available and 
supported when the bits are cleared to 0.  I believe the correct code should 
be: 


if ((AsmMsrBitFieldRead64 (MSR_IA32_MISC_ENABLE, 11, 11) != 0) ||
  (AsmMsrBitFieldRead64 (MSR_IA32_MISC_ENABLE, 12, 12) != 0)) {
//
// BTS facilities are disabled.
//
mBtsSupported = FALSE;
  }


Please let me know if I am misreading this code block.  I can create a patch if 
appropriate. 
___
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] Minor problems with dualboot VM. EFIVars?

[Blank Field]

Hi. I am attempting to rebuild my system with a host EFI bootloader,
namely GRUB.
I did a fresh install of F23(i've found that way easier than figuring
out how to migrate to EFI), turned off my CSM in host UEFI setup, got
my windows exVM booting in pure EFI, got my fedora booting in pure
EFI.

So, the host has it's ESP on the harddrive, which i am
passing-through(hey, seems like that bug with MBR.c got fixed
somehow).

Here are the contents of it:
http://paste.fedoraproject.org/360038/71386414/
As you can see, we have some weird stuff going on here(what's that
GUID?), but anyway.

When booting the VM (dumpxml will be attached somewhere later in the
timeline for the reasons described far below) i've got "System
BootOrder not found. Initializing defaults" and then it hangs.
dumpxml:

I do not know how to fix this.
My ideas:
1. copy the host EFIVARS to VM's EFIVARS storage somewhere in
/var/lib/libvirt...
2. try to choose the exact bootmgr64 or what's-it's-name windows
bootloader directly using either console UI OVMF provides or UefiShell
instead of just selecting the disk in the console UI.
3. (a really bad idea) add the second host drive where /boot/ relies,
so i could boot grub and select the proper .efi.
4. (a tedious idea) move /boot and grub to the hard drive, so the VM
could've access to it.

What should i do?


P.S.
Please note that i am not a developer of OVMF or edk2. It means that i
am subscribed to this list, but i am not receiving messages from this
list because endless PATCHes would fill up my mailbox.
P.P.S.
The reason for me not providing the dumpxml is...
Well, seems like the libvirtd on my system has a bug, which hangs it
dead when force stopping the VM. It would be pretty good if OVMF would
respond to regular libvirtd poweroff(i guess it emulates the acpi
button action) like a physical UEFI does - actually turn the machine
off.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] HMAC calculation clarification for TPM 1.2

[David Van Arnem]

Hi all,

I don't know if this is the correct place for this question, but I'm
hoping someone can provide insight.

I'm trying to calculate authorization HMACs for authenticated commands
with a TPM 1.2 from an EFI application, but I have not been able to get
the correct values the TPM expects.  The TPM uses RFC 2104 for its HMAC
calculations:

HMAC = H(K XOR opad, H(K XOR ipad, text))

where

H - SHA1
K - key or AuthData
ipad - B bytes of 0x36, where B is the block length, 64
opad - B bytes of 0x5C

When the TPM 1.2 Spec, Part 1 Design Principles (page 75), says:

sharedSecret = HMAC(key.usageAuth, nonceEvenOSAP, nonceOddOSAP)

How is this translated to the RFC 2104 equation, specifically the "text"
variable?  I tried:

text = nonceEvenOSAP || nonceOddOSAP (|| concatenation)

but that did not work.  I'm wondering if instead it should be:

text = SHA1(nonceEvenOSAP) || nonceOddOSAP

which more closely matches the format for AuthData HMACs associated with
an OSAP/OIAP session.  I would like clarification on this before I
implement it, since it is the key for other HMACs.

Thanks in advance!

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

[edk2] SATA/AHCI related queries

[Shaveta Leekha]

Hi,

I have referred the SATA Dxe code that in Ovmf commit:

commit b82802b83f069c7322337b802a744491010cbfb1
Author: Reza Jelveh >
Date:   Tue Sep 22 11:18:45 2015 +

OvmfPkg: enable SATA controller

I have few queries in same context.
The SATA driver I am writing is "SATA 3.0 AHCI host controller", with "AHCI 1.3 
specification"
I am trying to implement the complete code stack in following way:

?  Generic file system driver

?  Generic Partition driver

?  Generic DiskIo driver

?  Generic AtaBusDxe driver

?  Generic AtaAtapiPassThru driver consumes "EfiIdeControllerInitProtocol" and 
produces "EfiAtaPassThruProtocol" which is consumed by generic AtaBusDxe driver

?  Platform-specific SATA driver that produces "EfiIdeControllerInitProtocol"

?  Platform-specific PCI bus driver that install PCI IO protocol


Does "MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf" support AHCI 
1.3 ??
Does it support all the commands etc.

Do I need to write only initialization SATA code in Platform-specific SATA 
driver that produces "EfiIdeControllerInitProtocol" as highlighted above??
What is the role of SCSI protocol in this?

Kindly help in clearing these doubts.

Thanks and Regards,
Shaveta

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

Re: [edk2] [PATCH v3] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for image verification failures

[Laszlo Ersek]

On 04/26/16 19:47, El-Haj-Mahmoud, Samer wrote:
> Reviewed-by: Samer El-Haj-Mahmoud 
> 
> Chao or Laszlo, will one of you commit this please?

The only SecurityPkg maintainer is Chao (according to Maintainers.txt);
I can't commit the patch without his review.

Thanks
Laszlo

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Tuesday, April 26, 2016 12:17 PM
> To: Shia, Cinnamon ; edk2-de...@ml01.01.org
> Cc: El-Haj-Mahmoud, Samer ; 
> chao.b.zh...@intel.com
> Subject: Re: [PATCH v3] SecurityPkg/DxeImageVerificationLib: Add DEBUG 
> messages for image verification failures
> 
> On 04/26/16 18:51, Cinnamon Shia wrote:
>> Add DEBUG messages in DxeImageerificationLib to help debug Secure Boot 
>> image verification failures
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Cinnamon Shia 
>> Reviewed-by: Samer EL-Haj-Mahmoud 
>> ---
>>  .../DxeImageVerificationLib.c  | 49 
>> ++
>>  1 file changed, 41 insertions(+), 8 deletions(-)
> 
> Looks good to me, thank you.
> 
> I'm not a crypto expert, so I'll leave Reviewed-by tags to others. But, I'm 
> willing to give an:
> 
> Acked-by: Laszlo Ersek 
> 
> Also, I think Samer should re-review this patch (v3).
> 
> Thanks!
> Laszlo
> 
>> diff --git 
>> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.
>> c 
>> b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.
>> c
>> index 4b4d3bf..ee94dce 100644
>> --- 
>> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.
>> c
>> +++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerification
>> +++ Lib.c
>> @@ -13,6 +13,7 @@
>>untrusted PE/COFF image and validate its data structure within this image 
>> buffer before use.
>>  
>>  Copyright (c) 2009 - 2015, Intel Corporation. All rights 
>> reserved.
>> +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
>>  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 @@ -71,6 +72,8 @@ HASH_TABLE mHash[] = {
>>{ L"SHA512", 64, [32], 9, Sha512GetContextSize, 
>> Sha512Init, Sha512Update, Sha512Final}  };
>>  
>> +EFI_STRING mHashTypeStr;
>> +
>>  /**
>>SecureBoot Hook for processing image verification.
>>  
>> @@ -340,6 +343,7 @@ HashPeImage (
>>  return FALSE;
>>}
>>  
>> +  mHashTypeStr = mHash[HashAlg].Name;
>>CtxSize   = mHash[HashAlg].GetContextSize();
>>  
>>HashCtx = AllocatePool (CtxSize);
>> @@ -1782,14 +1786,16 @@ ImageVerificationInAuditMode (
>>UINT32   OffSet;
>>CHAR16   *FilePathStr;
>>UINTNSignatureListSize;
>> +  BOOLEAN  SigAcceptedByCertsInDb;
>>  
>> -  SignatureList = NULL;
>> -  WinCertificate= NULL;
>> -  SecDataDir= NULL;
>> -  PkcsCertData  = NULL;
>> -  FilePathStr   = NULL;
>> -  Action= EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED | 
>> EFI_IMAGE_EXECUTION_INITIALIZED;
>> -  Status= EFI_ACCESS_DENIED;
>> +  SignatureList  = NULL;
>> +  WinCertificate = NULL;
>> +  SecDataDir = NULL;
>> +  PkcsCertData   = NULL;
>> +  FilePathStr= NULL;
>> +  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED | 
>> EFI_IMAGE_EXECUTION_INITIALIZED;
>> +  Status = EFI_ACCESS_DENIED;
>> +  SigAcceptedByCertsInDb = FALSE;
>>  
>>  
>>//
>> @@ -1873,6 +1879,7 @@ ImageVerificationInAuditMode (
>>  //
>>  // The information can't be got from the invalid PeImage
>>  //
>> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid. 
>> + Cannot retrieve image information.\n"));
>>  goto END;
>>}
>>  
>> @@ -1896,6 +1903,7 @@ ImageVerificationInAuditMode (
>>  //
>>  // It is not a valid Pe/Coff file.
>>  //
>> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Not a valid 
>> + PE/COFF image.\n"));
>>  Status = EFI_ACCESS_DENIED;
>>  goto END;
>>}
>> @@ -1942,6 +1950,7 @@ ImageVerificationInAuditMode (
>>  // and not be reflected in the security data base "dbx".
>>  //
>>  if (!HashPeImage (HASHALG_SHA256)) {
>> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Failed to hash 
>> + this image using %s.\n", mHashTypeStr));
>>Status = EFI_ACCESS_DENIED;
>>goto END;
>>  }
>> @@ -1955,7 +1964,14 @@ ImageVerificationInAuditMode (
>>//
>>if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
>> mImageDigest, , mImageDigestSize)) {
>>  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
>> EFI_IMAGE_EXECUTION_INITIALIZED;
>> +  } else {
>> + 

Re: [edk2] [PATCH v3] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for image verification failures

[El-Haj-Mahmoud, Samer]

Reviewed-by: Samer El-Haj-Mahmoud 

Chao or Laszlo, will one of you commit this please?

Thanks,
--Samer

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, April 26, 2016 12:17 PM
To: Shia, Cinnamon ; edk2-de...@ml01.01.org
Cc: El-Haj-Mahmoud, Samer ; chao.b.zh...@intel.com
Subject: Re: [PATCH v3] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages 
for image verification failures

On 04/26/16 18:51, Cinnamon Shia wrote:
> Add DEBUG messages in DxeImageerificationLib to help debug Secure Boot 
> image verification failures
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Cinnamon Shia 
> Reviewed-by: Samer EL-Haj-Mahmoud 
> ---
>  .../DxeImageVerificationLib.c  | 49 
> ++
>  1 file changed, 41 insertions(+), 8 deletions(-)

Looks good to me, thank you.

I'm not a crypto expert, so I'll leave Reviewed-by tags to others. But, I'm 
willing to give an:

Acked-by: Laszlo Ersek 

Also, I think Samer should re-review this patch (v3).

Thanks!
Laszlo

> diff --git 
> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.
> c 
> b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.
> c
> index 4b4d3bf..ee94dce 100644
> --- 
> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.
> c
> +++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerification
> +++ Lib.c
> @@ -13,6 +13,7 @@
>untrusted PE/COFF image and validate its data structure within this image 
> buffer before use.
>  
>  Copyright (c) 2009 - 2015, Intel Corporation. All rights 
> reserved.
> +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  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 @@ -71,6 +72,8 @@ HASH_TABLE mHash[] = {
>{ L"SHA512", 64, [32], 9, Sha512GetContextSize, 
> Sha512Init, Sha512Update, Sha512Final}  };
>  
> +EFI_STRING mHashTypeStr;
> +
>  /**
>SecureBoot Hook for processing image verification.
>  
> @@ -340,6 +343,7 @@ HashPeImage (
>  return FALSE;
>}
>  
> +  mHashTypeStr = mHash[HashAlg].Name;
>CtxSize   = mHash[HashAlg].GetContextSize();
>  
>HashCtx = AllocatePool (CtxSize);
> @@ -1782,14 +1786,16 @@ ImageVerificationInAuditMode (
>UINT32   OffSet;
>CHAR16   *FilePathStr;
>UINTNSignatureListSize;
> +  BOOLEAN  SigAcceptedByCertsInDb;
>  
> -  SignatureList = NULL;
> -  WinCertificate= NULL;
> -  SecDataDir= NULL;
> -  PkcsCertData  = NULL;
> -  FilePathStr   = NULL;
> -  Action= EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED | 
> EFI_IMAGE_EXECUTION_INITIALIZED;
> -  Status= EFI_ACCESS_DENIED;
> +  SignatureList  = NULL;
> +  WinCertificate = NULL;
> +  SecDataDir = NULL;
> +  PkcsCertData   = NULL;
> +  FilePathStr= NULL;
> +  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED | 
> EFI_IMAGE_EXECUTION_INITIALIZED;
> +  Status = EFI_ACCESS_DENIED;
> +  SigAcceptedByCertsInDb = FALSE;
>  
>  
>//
> @@ -1873,6 +1879,7 @@ ImageVerificationInAuditMode (
>  //
>  // The information can't be got from the invalid PeImage
>  //
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid. 
> + Cannot retrieve image information.\n"));
>  goto END;
>}
>  
> @@ -1896,6 +1903,7 @@ ImageVerificationInAuditMode (
>  //
>  // It is not a valid Pe/Coff file.
>  //
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Not a valid 
> + PE/COFF image.\n"));
>  Status = EFI_ACCESS_DENIED;
>  goto END;
>}
> @@ -1942,6 +1950,7 @@ ImageVerificationInAuditMode (
>  // and not be reflected in the security data base "dbx".
>  //
>  if (!HashPeImage (HASHALG_SHA256)) {
> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Failed to hash 
> + this image using %s.\n", mHashTypeStr));
>Status = EFI_ACCESS_DENIED;
>goto END;
>  }
> @@ -1955,7 +1964,14 @@ ImageVerificationInAuditMode (
>//
>if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
> mImageDigest, , mImageDigestSize)) {
>  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
> EFI_IMAGE_EXECUTION_INITIALIZED;
> +  } else {
> +//
> +// Image Hash is not in DB/DBX
> +//
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not 
> + signed and %s hash of image is not found in DB/DBX.\n", 
> + mHashTypeStr));
>}
> +} else {
> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not 
> + 

Re: [edk2] [PATCH v3] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for image verification failures

[Laszlo Ersek]

On 04/26/16 18:51, Cinnamon Shia wrote:
> Add DEBUG messages in DxeImageerificationLib to help debug Secure Boot image 
> verification failures
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Cinnamon Shia 
> Reviewed-by: Samer EL-Haj-Mahmoud 
> ---
>  .../DxeImageVerificationLib.c  | 49 
> ++
>  1 file changed, 41 insertions(+), 8 deletions(-)

Looks good to me, thank you.

I'm not a crypto expert, so I'll leave Reviewed-by tags to others. But,
I'm willing to give an:

Acked-by: Laszlo Ersek 

Also, I think Samer should re-review this patch (v3).

Thanks!
Laszlo

> diff --git 
> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c 
> b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> index 4b4d3bf..ee94dce 100644
> --- a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> +++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> @@ -13,6 +13,7 @@
>untrusted PE/COFF image and validate its data structure within this image 
> buffer before use.
>  
>  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
> +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  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
> @@ -71,6 +72,8 @@ HASH_TABLE mHash[] = {
>{ L"SHA512", 64, [32], 9, Sha512GetContextSize, Sha512Init, 
> Sha512Update, Sha512Final}
>  };
>  
> +EFI_STRING mHashTypeStr;
> +
>  /**
>SecureBoot Hook for processing image verification.
>  
> @@ -340,6 +343,7 @@ HashPeImage (
>  return FALSE;
>}
>  
> +  mHashTypeStr = mHash[HashAlg].Name;
>CtxSize   = mHash[HashAlg].GetContextSize();
>  
>HashCtx = AllocatePool (CtxSize);
> @@ -1782,14 +1786,16 @@ ImageVerificationInAuditMode (
>UINT32   OffSet;
>CHAR16   *FilePathStr;
>UINTNSignatureListSize;
> +  BOOLEAN  SigAcceptedByCertsInDb;
>  
> -  SignatureList = NULL;
> -  WinCertificate= NULL;
> -  SecDataDir= NULL;
> -  PkcsCertData  = NULL;
> -  FilePathStr   = NULL;
> -  Action= EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED | 
> EFI_IMAGE_EXECUTION_INITIALIZED;
> -  Status= EFI_ACCESS_DENIED;
> +  SignatureList  = NULL;
> +  WinCertificate = NULL;
> +  SecDataDir = NULL;
> +  PkcsCertData   = NULL;
> +  FilePathStr= NULL;
> +  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED | 
> EFI_IMAGE_EXECUTION_INITIALIZED;
> +  Status = EFI_ACCESS_DENIED;
> +  SigAcceptedByCertsInDb = FALSE;
>  
>  
>//
> @@ -1873,6 +1879,7 @@ ImageVerificationInAuditMode (
>  //
>  // The information can't be got from the invalid PeImage
>  //
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid. Cannot 
> retrieve image information.\n"));
>  goto END;
>}
>  
> @@ -1896,6 +1903,7 @@ ImageVerificationInAuditMode (
>  //
>  // It is not a valid Pe/Coff file.
>  //
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Not a valid PE/COFF 
> image.\n"));
>  Status = EFI_ACCESS_DENIED;
>  goto END;
>}
> @@ -1942,6 +1950,7 @@ ImageVerificationInAuditMode (
>  // and not be reflected in the security data base "dbx".
>  //
>  if (!HashPeImage (HASHALG_SHA256)) {
> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Failed to hash this 
> image using %s.\n", mHashTypeStr));
>Status = EFI_ACCESS_DENIED;
>goto END;
>  }
> @@ -1955,7 +1964,14 @@ ImageVerificationInAuditMode (
>//
>if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
> mImageDigest, , mImageDigestSize)) {
>  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
> EFI_IMAGE_EXECUTION_INITIALIZED;
> +  } else {
> +//
> +// Image Hash is not in DB/DBX
> +//
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not signed 
> and %s hash of image is not found in DB/DBX.\n", mHashTypeStr));
>}
> +} else {
> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not signed and 
> %s hash of image is rejected by DBX.\n", mHashTypeStr));
>  }
>  
>  //
> @@ -2029,7 +2045,9 @@ ImageVerificationInAuditMode (
>  // Check the digital signature against the valid certificate in allowed 
> database (db).
>  //
>  if (!IsForbiddenByDbx (AuthData, AuthDataSize, TRUE, FilePathStr, File)) 
> {
> -  IsAllowedByDb (AuthData, AuthDataSize, TRUE, FilePathStr, File);
> +  SigAcceptedByCertsInDb = IsAllowedByDb (AuthData, AuthDataSize, TRUE, 
> FilePathStr, File);
> +} else {
> + 

Re: [edk2] Questions on write access to edk2-staging

[El-Haj-Mahmoud, Samer]

Mike, Laszlo,

Thanks for the answers.

--Samer

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, April 26, 2016 12:13 PM
To: Kinney, Michael D ; El-Haj-Mahmoud, Samer 
; edk2-devel@lists.01.org 
; Mangefeste, Tony ; Andrew 
Fish 
Subject: Re: Questions on write access to edk2-staging

On 04/26/16 19:04, Kinney, Michael D wrote:
> Samer,
> 
> Access to edk2-staging should be identical to edk2.  
> 
> Every feature branch on edk2-staging requires one or more 
> maintainer(s) with write access to support updates to a feature branch in 
> edk2-staging.
> 
> If a developer does not have write access to edk2-staging, then they 
> need to share changes with one of the maintainer(s) that is supporting 
> the edk2-staging feature branch.
> 
> Pull requests are being evaluated for edk2 trunk.
> 
> Right now, there are no changes to the way changes are made to edk2 trunk.  
> Once a feature branch in edk-2staging is ready for edk2 trunk, email 
> patch reviews should be sent to edk2-devel.
> 
> Feature branches in edk2-staging can be managed using any method(s) 
> the
> maintainer(s) for that feature branch decide.  Probably a good idea to 
> document the method(s) being used in the Readme.md in the root of the 
> feature branch.

I think this is a good idea -- if a maintainer wants to accept github pull reqs 
(or emailed pull reqs) for his/her edk2-staging branch, that should be 
permitted. This way the maintainer might even gather experience with pull 
requests in general (for the time when / if edk2 will enable pulls as well).

Thanks
Laszlo

> Best regards,
> 
> Mike
> 
> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>> Of El-Haj-Mahmoud, Samer
>> Sent: Tuesday, April 26, 2016 9:35 AM
>> To: edk2-devel@lists.01.org; Kinney, Michael D 
>> ; Mangefeste, Tony 
>> ; Andrew Fish ; Laszlo 
>> Ersek 
>> Subject: [edk2] Questions on write access to edk2-staging
>>
>> What is the process of requesting write access to edk2-staging?
>>
>>
>> *Should only module and tree maintainers have write access (similar 
>> to edk2)?
>>
>> *Should developers working on contributing to the feature branches 
>> have write
>> access?
>>
>> Also related:
>>
>>
>> *Should developers use pull requests on a branch to commit a change 
>> (after it
>> gets reviewed through the official process on edk2-devel)?
>>
>> Thanks,
>> --Samer
>> ___
>> 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] Questions on write access to edk2-staging

[Laszlo Ersek]

On 04/26/16 19:04, Kinney, Michael D wrote:
> Samer,
> 
> Access to edk2-staging should be identical to edk2.  
> 
> Every feature branch on edk2-staging requires one or more maintainer(s) 
> with write access to support updates to a feature branch in edk2-staging.
> 
> If a developer does not have write access to edk2-staging, then they 
> need to share changes with one of the maintainer(s) that is supporting 
> the edk2-staging feature branch.
> 
> Pull requests are being evaluated for edk2 trunk.
> 
> Right now, there are no changes to the way changes are made to edk2 trunk.  
> Once a feature branch in edk-2staging is ready for edk2 trunk, email patch 
> reviews should be sent to edk2-devel.
> 
> Feature branches in edk2-staging can be managed using any method(s) the 
> maintainer(s) for that feature branch decide.  Probably a good idea to
> document the method(s) being used in the Readme.md in the root of the 
> feature branch.

I think this is a good idea -- if a maintainer wants to accept github
pull reqs (or emailed pull reqs) for his/her edk2-staging branch, that
should be permitted. This way the maintainer might even gather
experience with pull requests in general (for the time when / if edk2
will enable pulls as well).

Thanks
Laszlo

> Best regards,
> 
> Mike
> 
> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> El-Haj-Mahmoud,
>> Samer
>> Sent: Tuesday, April 26, 2016 9:35 AM
>> To: edk2-devel@lists.01.org; Kinney, Michael D ;
>> Mangefeste, Tony ; Andrew Fish ; 
>> Laszlo
>> Ersek 
>> Subject: [edk2] Questions on write access to edk2-staging
>>
>> What is the process of requesting write access to edk2-staging?
>>
>>
>> *Should only module and tree maintainers have write access (similar 
>> to edk2)?
>>
>> *Should developers working on contributing to the feature branches 
>> have write
>> access?
>>
>> Also related:
>>
>>
>> *Should developers use pull requests on a branch to commit a change 
>> (after it
>> gets reviewed through the official process on edk2-devel)?
>>
>> Thanks,
>> --Samer
>> ___
>> 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] Questions on write access to edk2-staging

[Kinney, Michael D]

Samer,

Access to edk2-staging should be identical to edk2.  

Every feature branch on edk2-staging requires one or more maintainer(s) 
with write access to support updates to a feature branch in edk2-staging.

If a developer does not have write access to edk2-staging, then they 
need to share changes with one of the maintainer(s) that is supporting 
the edk2-staging feature branch.

Pull requests are being evaluated for edk2 trunk.

Right now, there are no changes to the way changes are made to edk2 trunk.  
Once a feature branch in edk-2staging is ready for edk2 trunk, email patch 
reviews should be sent to edk2-devel.

Feature branches in edk2-staging can be managed using any method(s) the 
maintainer(s) for that feature branch decide.  Probably a good idea to
document the method(s) being used in the Readme.md in the root of the 
feature branch.

Best regards,

Mike



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> El-Haj-Mahmoud,
> Samer
> Sent: Tuesday, April 26, 2016 9:35 AM
> To: edk2-devel@lists.01.org; Kinney, Michael D ;
> Mangefeste, Tony ; Andrew Fish ; 
> Laszlo
> Ersek 
> Subject: [edk2] Questions on write access to edk2-staging
> 
> What is the process of requesting write access to edk2-staging?
> 
> 
> *Should only module and tree maintainers have write access (similar 
> to edk2)?
> 
> *Should developers working on contributing to the feature branches 
> have write
> access?
> 
> Also related:
> 
> 
> *Should developers use pull requests on a branch to commit a change 
> (after it
> gets reviewed through the official process on edk2-devel)?
> 
> Thanks,
> --Samer
> ___
> 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] Question about SmmProfile logic

[Shifflett, Joseph]

I have a question about the logic of this code here:

https://svn.code.sf.net/p/edk2/code/trunk/edk2/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c

>From Line 958:

  if (mBtsSupported) {
AsmCpuid (CPUID_VERSION_INFO, NULL, NULL, NULL, );
if ((RegEdx & CPUID1_EDX_BTS_AVAILABLE) != 0) {
  //
  // Per IA32 manuals:
  // When CPUID.1:EDX[21] is set, the following BTS facilities are 
available:
  // 1. The BTS_UNAVAILABLE flag in the IA32_MISC_ENABLE MSR indicates the
  //availability of the BTS facilities, including the ability to set 
the BTS and
  //BTINT bits in the MSR_DEBUGCTLA MSR.
  // 2. The IA32_DS_AREA MSR can be programmed to point to the DS save area.
  //
  if ((AsmMsrBitFieldRead64 (MSR_IA32_MISC_ENABLE, 11, 11) == 0) &&
  (AsmMsrBitFieldRead64 (MSR_IA32_MISC_ENABLE, 12, 12) == 0)) {
//
// BTS facilities is supported.
//
mBtsSupported = FALSE;
  }
}
  }


According to Volume 3 of the Intel 64 and IA-32 Architectures Software 
Developer's Manual 
(http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf),
 bits 11 and 12 of MSR _01A0 indicate BTS and PEBS are available and 
supported when the bits are cleared to 0.  I believe the correct code should 
be: 


if ((AsmMsrBitFieldRead64 (MSR_IA32_MISC_ENABLE, 11, 11) != 0) ||
  (AsmMsrBitFieldRead64 (MSR_IA32_MISC_ENABLE, 12, 12) != 0)) {
//
// BTS facilities are disabled.
//
mBtsSupported = FALSE;
  }


Please let me know if I am misreading this code block.  I can create a patch if 
appropriate. 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for image verification failures

[Cinnamon Shia]

Add DEBUG messages in DxeImageerificationLib to help debug Secure Boot image 
verification failures

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
Reviewed-by: Samer EL-Haj-Mahmoud 
---
 .../DxeImageVerificationLib.c  | 49 ++
 1 file changed, 41 insertions(+), 8 deletions(-)

diff --git 
a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c 
b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
index 4b4d3bf..ee94dce 100644
--- a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
+++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
@@ -13,6 +13,7 @@
   untrusted PE/COFF image and validate its data structure within this image 
buffer before use.
 
 Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2016 Hewlett Packard Enterprise Development LP
 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
@@ -71,6 +72,8 @@ HASH_TABLE mHash[] = {
   { L"SHA512", 64, [32], 9, Sha512GetContextSize, Sha512Init, 
Sha512Update, Sha512Final}
 };
 
+EFI_STRING mHashTypeStr;
+
 /**
   SecureBoot Hook for processing image verification.
 
@@ -340,6 +343,7 @@ HashPeImage (
 return FALSE;
   }
 
+  mHashTypeStr = mHash[HashAlg].Name;
   CtxSize   = mHash[HashAlg].GetContextSize();
 
   HashCtx = AllocatePool (CtxSize);
@@ -1782,14 +1786,16 @@ ImageVerificationInAuditMode (
   UINT32   OffSet;
   CHAR16   *FilePathStr;
   UINTNSignatureListSize;
+  BOOLEAN  SigAcceptedByCertsInDb;
 
-  SignatureList = NULL;
-  WinCertificate= NULL;
-  SecDataDir= NULL;
-  PkcsCertData  = NULL;
-  FilePathStr   = NULL;
-  Action= EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED | 
EFI_IMAGE_EXECUTION_INITIALIZED;
-  Status= EFI_ACCESS_DENIED;
+  SignatureList  = NULL;
+  WinCertificate = NULL;
+  SecDataDir = NULL;
+  PkcsCertData   = NULL;
+  FilePathStr= NULL;
+  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED | 
EFI_IMAGE_EXECUTION_INITIALIZED;
+  Status = EFI_ACCESS_DENIED;
+  SigAcceptedByCertsInDb = FALSE;
 
 
   //
@@ -1873,6 +1879,7 @@ ImageVerificationInAuditMode (
 //
 // The information can't be got from the invalid PeImage
 //
+DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid. Cannot 
retrieve image information.\n"));
 goto END;
   }
 
@@ -1896,6 +1903,7 @@ ImageVerificationInAuditMode (
 //
 // It is not a valid Pe/Coff file.
 //
+DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Not a valid PE/COFF 
image.\n"));
 Status = EFI_ACCESS_DENIED;
 goto END;
   }
@@ -1942,6 +1950,7 @@ ImageVerificationInAuditMode (
 // and not be reflected in the security data base "dbx".
 //
 if (!HashPeImage (HASHALG_SHA256)) {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Failed to hash this image 
using %s.\n", mHashTypeStr));
   Status = EFI_ACCESS_DENIED;
   goto END;
 }
@@ -1955,7 +1964,14 @@ ImageVerificationInAuditMode (
   //
   if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
mImageDigest, , mImageDigestSize)) {
 Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
EFI_IMAGE_EXECUTION_INITIALIZED;
+  } else {
+//
+// Image Hash is not in DB/DBX
+//
+DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not signed and 
%s hash of image is not found in DB/DBX.\n", mHashTypeStr));
   }
+} else {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not signed and 
%s hash of image is rejected by DBX.\n", mHashTypeStr));
 }
 
 //
@@ -2029,7 +2045,9 @@ ImageVerificationInAuditMode (
 // Check the digital signature against the valid certificate in allowed 
database (db).
 //
 if (!IsForbiddenByDbx (AuthData, AuthDataSize, TRUE, FilePathStr, File)) {
-  IsAllowedByDb (AuthData, AuthDataSize, TRUE, FilePathStr, File);
+  SigAcceptedByCertsInDb = IsAllowedByDb (AuthData, AuthDataSize, TRUE, 
FilePathStr, File);
+} else {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is signed but 
signature is rejected by DBX.\n"));
 }
 
 //
@@ -2038,7 +2056,13 @@ ImageVerificationInAuditMode (
 if (!IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE1, 
mImageDigest, , mImageDigestSize)) {
   if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
mImageDigest, , mImageDigestSize)) {
 Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
EFI_IMAGE_EXECUTION_INITIALIZED; 
+  } else {
+if (!SigAcceptedByCertsInDb) {

Re: [edk2] [PATCH v1] MdePkg:Http11.h: Add defines for "Expect" header

[El-Haj-Mahmoud, Samer]

Reviewed-by: Samer El-Haj-Mahmoud 


-Original Message-
From: Hegde, Nagaraj P 
Sent: Monday, April 25, 2016 10:47 PM
To: edk2-devel@lists.01.org
Cc: jiaxin...@intel.com; siyuan...@intel.com; ting...@intel.com; 
El-Haj-Mahmoud, Samer 
Subject: [PATCH v1] MdePkg:Http11.h: Add defines for "Expect" header

Add #defines for "Expect" header, which is a part of RFC 2616 and used for HTTP 
PUT/POST operations.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hegde, Nagaraj P 
---
 MdePkg/Include/IndustryStandard/Http11.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/MdePkg/Include/IndustryStandard/Http11.h 
b/MdePkg/Include/IndustryStandard/Http11.h
index 8a09f96..f735430 100644
--- a/MdePkg/Include/IndustryStandard/Http11.h
+++ b/MdePkg/Include/IndustryStandard/Http11.h
@@ -234,6 +234,19 @@
 /// Example: X-Auth-Token: 24de6b1f8fa147ad59f6452def628798
 ///
 #define  HTTP_HEADER_X_AUTH_TOKEN  "X-Auth-Token"
+///
+/// Expect Header
+/// The "Expect" header field in a request indicates a certain set of 
+/// behaviors (expectations) that need to be supported by the server in 
+/// order to properly handle this request. The only such expectation 
+/// defined by this specification is 100-continue.
+///
+#define  HTTP_HEADER_EXPECT"Expect"
+
+///
+/// Expect Header Value
+///
+#define  HTTP_EXPECT_100_CONTINUE   "100-continue"
 
 #pragma pack()
 
--
2.6.2.windows.1

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

Re: [edk2] [PATCH v2] NetworkPkg: Allow user to create a HTTP corporate boot option in setup page.

[El-Haj-Mahmoud, Samer]

Reviewed-by: Samer El-Haj-Mahmoud 



-Original Message-
From: Fu, Siyuan
Sent: Tuesday, April 26, 2016 11:47 AM
To: edk2-devel@lists.01.org
Cc: Li Gary ; Ye, Ting ; Wu, Jiaxin 

Subject: [PATCH v2] NetworkPkg: Allow user to create a HTTP corporate boot 
option in setup page.

This patch updates the HTTP Boot Configuration page to allow the user to create 
a corporate mode HTTP boot option, by leaving the URI string empty.
The patch also fix a bug that the L"https://; should use StrnCmp() with Length 
8.

Cc: Li Gary 
Cc: Ye Ting 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpBootDxe/HttpBootConfig.c| 9 +
 NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h | 2 +-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfig.c 
b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
index c47dddc..00e4782 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
@@ -79,9 +79,9 @@ HttpBootAddBootOption (
   }
 
   //
-  // Only accept http and https URI.
+  // Only accept empty URI, or http and https URI.
   //
-  if ((StrnCmp (Uri, L"http://;, 7) != 0) && (StrnCmp (Uri, L"https://;, 7) != 
0)) {
+  if ((StrLen (Uri) != 0) && (StrnCmp (Uri, L"http://;, 7) != 0) && 
+ (StrnCmp (Uri, L"https://;, 8) != 0)) {
 return EFI_INVALID_PARAMETER;
   }
   
@@ -577,9 +577,10 @@ HttpBootFormCallback (
 HiiSetString (CallbackInfo->RegisteredHandle, Value->string, Uri, NULL);
 
 //
-// We only accept http and https, pop up a message box for unsupported URI.
+// The URI should be either an empty string (for corporate environment) 
,or http(s) for home environment.
+// Pop up a message box for other unsupported URI.
 //
-if ((StrnCmp (Uri, L"http://;, 7) != 0) && (StrnCmp (Uri, L"https://;, 7) 
!= 0)) {
+if ((StrLen (Uri) != 0) && (StrnCmp (Uri, L"http://;, 7) != 0) && 
+ (StrnCmp (Uri, L"https://;, 8) != 0)) {
   CreatePopUp (
 EFI_LIGHTGRAY | EFI_BACKGROUND_BLUE,
 ,
diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h 
b/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
index 37ce440..682306e 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
+++ b/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
@@ -23,7 +23,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 //
 // Macros used for an IPv4 or an IPv6 address.
 //
-#define URI_STR_MIN_SIZE 8
+#define URI_STR_MIN_SIZE 0
 #define URI_STR_MAX_SIZE 255
 
 #define DESCRIPTION_STR_MIN_SIZE 6
--
2.7.4.windows.1

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

Re: [edk2] [PATCH v2] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for image verification failures

[Shia, Cinnamon]

Agreed. Will fixed it in the v3 patch.

Thanks,
Cinnamon Shia

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, April 26, 2016 11:54 PM
To: Shia, Cinnamon ; edk2-de...@ml01.01.org
Cc: El-Haj-Mahmoud, Samer ; chao.b.zh...@intel.com
Subject: Re: [PATCH v2] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages 
for image verification failures

On 04/26/16 17:22, Cinnamon Shia wrote:
> Add DEBUG messages in DxeImageerificationLib to help debug Secure Boot 
> image verification failures
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Cinnamon Shia 
> Reviewed-by: Samer EL-Haj-Mahmoud 
> ---
>  .../DxeImageVerificationLib.c  | 37 
> +-
>  1 file changed, 36 insertions(+), 1 deletion(-)

... Sorry, I feel quite dumb. :(

I have now actually checked what IsAllowedByDb does, and it says:

  "Check whether the image signature can be verified by the trusted
  certificates in DB database."

In other words, it is not a direct hash match, but a certificate chain match. 
So the variable should not be called "SigFoundInDb" after all, but something 
like "SigAcceptedByCertsInDb". I feel very bad that I realized this just now. :(

Another comment:

> diff --git 
> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.
> c 
> b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.
> c
> index 4b4d3bf..95c0007 100644
> --- 
> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.
> c
> +++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerification
> +++ Lib.c
> @@ -13,6 +13,7 @@
>untrusted PE/COFF image and validate its data structure within this image 
> buffer before use.
>  
>  Copyright (c) 2009 - 2015, Intel Corporation. All rights 
> reserved.
> +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  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 @@ -71,6 +72,8 @@ HASH_TABLE mHash[] = {
>{ L"SHA512", 64, [32], 9, Sha512GetContextSize, 
> Sha512Init, Sha512Update, Sha512Final}  };
>  
> +EFI_STRING mHashTypeStr;
> +
>  /**
>SecureBoot Hook for processing image verification.
>  
> @@ -340,6 +343,7 @@ HashPeImage (
>  return FALSE;
>}
>  
> +  mHashTypeStr = mHash[HashAlg].Name;
>CtxSize   = mHash[HashAlg].GetContextSize();
>  
>HashCtx = AllocatePool (CtxSize);
> @@ -1782,6 +1786,7 @@ ImageVerificationInAuditMode (
>UINT32   OffSet;
>CHAR16   *FilePathStr;
>UINTNSignatureListSize;
> +  BOOLEAN  SigFoundInDb;
>  
>SignatureList = NULL;
>WinCertificate= NULL;
> @@ -1790,6 +1795,7 @@ ImageVerificationInAuditMode (
>FilePathStr   = NULL;
>Action= EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED | 
> EFI_IMAGE_EXECUTION_INITIALIZED;
>Status= EFI_ACCESS_DENIED;
> +  SigFoundInDb  = FALSE;
>  
>  
>//
> @@ -1873,6 +1879,7 @@ ImageVerificationInAuditMode (
>  //
>  // The information can't be got from the invalid PeImage
>  //
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid. 
> + Cannot retrieve image information.\n"));
>  goto END;
>}
>  
> @@ -1896,6 +1903,7 @@ ImageVerificationInAuditMode (
>  //
>  // It is not a valid Pe/Coff file.
>  //
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Not a valid 
> + PE/COFF image.\n"));
>  Status = EFI_ACCESS_DENIED;
>  goto END;
>}
> @@ -1942,6 +1950,7 @@ ImageVerificationInAuditMode (
>  // and not be reflected in the security data base "dbx".
>  //
>  if (!HashPeImage (HASHALG_SHA256)) {
> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Failed to hash 
> + this image using %s.\n", mHashTypeStr));
>Status = EFI_ACCESS_DENIED;
>goto END;
>  }
> @@ -1955,7 +1964,14 @@ ImageVerificationInAuditMode (
>//
>if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
> mImageDigest, , mImageDigestSize)) {
>  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
> EFI_IMAGE_EXECUTION_INITIALIZED;
> +  } else {
> +//
> +// Image Hash is not in DB/DBX
> +//
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not 
> + signed and %s hash of image is not found in DB/DBX.\n", 
> + mHashTypeStr));
>}
> +} else {
> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not 
> + signed and %s hash of image is rejected by DBX.\n", mHashTypeStr));
>  }
>  
>  //
> @@ -2029,7 +2045,9 @@ ImageVerificationInAuditMode (
>  // Check the digital signature against the valid 

Re: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when certificate is added to store multiple times

[El-Haj-Mahmoud, Samer]

Does not look like I have write permission to edk2-staging... I sent a separate 
email with question on the write access permissions for edk2-staging

I also created a pull request against the edk2-staging/https-tls branch: 
https://github.com/tianocore/edk2-staging/pull/1



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wu, 
Jiaxin
Sent: Monday, April 25, 2016 8:54 PM
To: El-Haj-Mahmoud, Samer ; Carsey, Jaben 

Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when certificate is 
added to store multiple times

Please let me know whether you can commit the patch:).

Thanks.
Jiaxin

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
Sent: Tuesday, April 26, 2016 9:41 AM
To: Carsey, Jaben ; Wu, Jiaxin 
Cc: edk2-devel@lists.01.org; Palmer, Thomas 
Subject: RE: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when certificate is 
added to store multiple times

Thanks for the prefix tip! Will try that next time.

I don't know if I have write access to the branch. I will give it a try.




-Original Message-
From: Wu, Jiaxin [jiaxin...@intel.com]
Received: Monday, 25 Apr 2016, 7:43PM
To: Carsey, Jaben [jaben.car...@intel.com]; El-Haj-Mahmoud, Samer 
[samer.el-haj-mahm...@hpe.com]
CC: edk2-devel@lists.01.org 
[edk2-devel@lists.01.org]; Palmer, Thomas [thomas.pal...@hpe.com]
Subject: RE: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when certificate is 
added to store multiple times Hi Samer,

I think the prefix with " staging/branch][PATCH " should be good to the staging 
patch subject.

For example:
*git format-patch  --subject-prefix="staging/HTTPS-TLS][PATCH"*

Then, you will get the patch with "[staging/HTTPS-TLS][PATCH]" subject.

The patch fix is good to me. Thanks for this contribution.

Reviewed-by: Jiaxin Wu >

BTW, Do you commit the patch by yourself or need I help to check in the patch?

Best Regards!
Jiaxin

> -Original Message-
> From: Carsey, Jaben
> Sent: Tuesday, April 26, 2016 4:00 AM
> To: El-Haj-Mahmoud, Samer 
> >
> Cc: edk2-devel@lists.01.org; Wu, 
> Jiaxin >; Palmer, 
> Thomas >
> Subject: Re: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when 
> certificate is added to store multiple times
>
> Ok. You can rb me, but I don't maintain that pkg so...
>
> Reviewed-by Jaben Carsey 
> >
>
> -Jaben
>
> > On Apr 25, 2016, at 11:17 AM, El-Haj-Mahmoud, Samer  mahm...@hpe.com> wrote:
> >
> > Thanks Jaben. I did notice this and tried to submit the patch with 
> > the
> modified subject (using git send-email with both --subject and 
> --compose), but that didn't work for some reason.
> >
> > Some answers below...
> >
> >
> > -Original Message-
> > From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> > Sent: Monday, April 25, 2016 12:54 PM
> > To: El-Haj-Mahmoud, Samer 
> > >;
> > edk2-devel@lists.01.org
> > Cc: El-Haj-Mahmoud, Samer 
> > >; 
> > Wu,
> Jiaxin
> > >; Carsey, Jaben 
> > >
> > Subject: RE: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when 
> > certificate is added to store multiple times
> >
> > Samer,
> >
> > Note: This is not in the EDK2 yet, but in the staging... change 
> > [PATCH] to [Staging/HTTPS-TLS PATCH] (or something like that per the
> > rules...)
> >
> > 2 questions inline also.
> >
> > -Jaben
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> >> Of Samer El-Haj-Mahmoud
> >> Sent: Monday, April 25, 2016 10:15 AM
> >> To: edk2-devel@lists.01.org
> >> Cc: Samer El-Haj-Mahmoud >; Wu, 
> >> Jiaxin >
> >> Subject: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when 
> >> certificate is added to store multiple times
> >>
> >> Removed unnecessary error condition in TLS Lib that that would 
> >> report an error if a certificate is being added to the X509_STORE more 
> >> than once.
> >> This causes HTTPS to fail on second attempt with the same certificate.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Samer El-Haj-Mahmoud 
> >> >
> >> Signed-off-by: Thomas Palmer 
> >> 

[edk2] Questions on write access to edk2-staging

[El-Haj-Mahmoud, Samer]

What is the process of requesting write access to edk2-staging?


*Should only module and tree maintainers have write access (similar to 
edk2)?

*Should developers working on contributing to the feature branches have 
write access?

Also related:


*Should developers use pull requests on a branch to commit a change 
(after it gets reviewed through the official process on edk2-devel)?

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

Re: [edk2] [PATCH] MdeModulePkg/TerminalDxe: Set polling rate by serial IO mode

[Kinney, Michael D]

Heyi,

I agree the source code required to detect the current tick rate using only 
UEFI services
is more complex.

However, a UEFI driver (especially ones on an add-in devices such as a PCI 
adapter) should not
use a PCD for the system tick rate because the add-in card can be used in 
systems with different
system tick rates.

If you are concerned about complexity, we could consider adding a new lib 
function to the
UefiLib that returns the current system tick rate using UEFI services to detect 
it.  This way, 
A UEFI driver can be kept simple and we move the complexity into a single new 
lib function.

Best regards,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi 
> Guo
> Sent: Tuesday, April 26, 2016 8:14 AM
> To: Kinney, Michael D ; edk2-devel@lists.01.org
> Cc: Tian, Feng ; Zeng, Star 
> Subject: Re: [edk2] [PATCH] MdeModulePkg/TerminalDxe: Set polling rate by 
> serial IO
> mode
> 
> Hi Michael,
> 
> It seems we are making the implementation more and more complicated. How
> about just creating a PCD for polling rate which can be set freely by
> platforms?
> 
> Regards.
> 
> Heyi
> 
> On 04/24/2016 12:11 AM, Kinney, Michael D wrote:
> > Heyi Guo,
> >
> > The TerminalDxe driver is intended to be a UEFI Driver.  The Timer Arch 
> > Protocol is
> > a PI Protocol that is intended to be used by the PI DXE Core.  In order to 
> > determine
> > the timer rate in a UEFI way, create a periodic timer event with a period 
> > of 1, 100ns
> > unit, and then measure the time between timer event notification functions.
> >
> > Mike
> >
> >> -Original Message-
> >> From: Heyi Guo [mailto:heyi@linaro.org]
> >> Sent: Saturday, April 23, 2016 1:54 AM
> >> To: edk2-devel@lists.01.org
> >> Cc: Heyi Guo ; Tian, Feng ; 
> >> Zeng, Star
> >> ; Kinney, Michael D 
> >> Subject: [edk2] [PATCH] MdeModulePkg/TerminalDxe: Set polling rate by 
> >> serial IO mode
> >>
> >> Calculate serial input polling rate according to parameters from
> >> serial IO mode as below, to fix potential input truncation.
> >>
> >> Polling interval (100ns) =
> >> FifoDepth * (StartBit + DataBits + StopBits + ParityBits) * 10,000,000
> >> / BaudRate
> >> (StopBits is assumed to be 1 and ParityBits is ignored for simplicity.
> >>
> >> However, as the event is time sensitive, we need to align the interval
> >> to timer interrupt period to make sure the event will be triggered at
> >> the expected rate. E.g. if the interval is 2.7ms and timer interrupt
> >> period is 1ms, the event will be triggered by time slice sequence as
> >> below:
> >> 3ms 3ms 2ms 3ms 3ms 2ms...
> >>
> >> In such case we will adjust the polling interval to be 2ms.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Heyi Guo 
> >> Cc: Feng Tian 
> >> Cc: Star Zeng 
> >> Cc: Michael D Kinney 
> >> ---
> >>   .../Universal/Console/TerminalDxe/Terminal.c   |  5 +-
> >>   .../Universal/Console/TerminalDxe/Terminal.h   | 28 ++-
> >>   .../Universal/Console/TerminalDxe/TerminalConIn.c  | 92 
> >> ++
> >>   .../Universal/Console/TerminalDxe/TerminalDxe.inf  |  1 +
> >>   4 files changed, 123 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
> >> b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
> >> index 6fde3b2..2944707 100644
> >> --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
> >> +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
> >> @@ -71,6 +71,7 @@ TERMINAL_DEV  mTerminalDevTemplate = {
> >> },
> >> NULL, // TerminalConsoleModeData
> >> 0,  // SerialInTimeOut
> >> +  0,  // KeyboardTimerInterval
> >>
> >> NULL, // RawFifo
> >> NULL, // UnicodeFiFo
> >> @@ -984,10 +985,12 @@ TerminalDriverBindingStart (
> >>   );
> >>   ASSERT_EFI_ERROR (Status);
> >>
> >> +TerminalDevice->KeyboardTimerInterval = GetKeyboardTimerInterval 
> >> (Mode);
> >> +
> >>   Status = gBS->SetTimer (
> >>   TerminalDevice->TimerEvent,
> >>   TimerPeriodic,
> >> -KEYBOARD_TIMER_INTERVAL
> >> +TerminalDevice->KeyboardTimerInterval
> >>   );
> >>   ASSERT_EFI_ERROR (Status);
> >>
> >> diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
> >> b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
> >> index 269d2ae..a1ff595 100644
> >> --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
> >> +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
> >> @@ -28,6 +28,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, 
> >> EITHER EXPRESS
> >> OR IMPLIED.
> >>   

Re: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when certificate is added to store multiple times

[El-Haj-Mahmoud, Samer]

Thanks Laszlo. I tried this and it worked...

git format-patch  --subject-prefix="staging/HTTPS-TLS][PATCH"



-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, April 26, 2016 6:16 AM
To: Wu, Jiaxin ; Carsey, Jaben ; 
El-Haj-Mahmoud, Samer 
Cc: edk2-devel@lists.01.org 
Subject: Re: [edk2] [PATCH] CryptoPkg: Fix TLS Lib issue when certificate is 
added to store multiple times

On 04/26/16 02:43, Wu, Jiaxin wrote:
> Hi Samer,
> 
> I think the prefix with " staging/branch][PATCH " should be good to the 
> staging patch subject.
> 
> For example:
> *git format-patch  --subject-prefix="staging/HTTPS-TLS][PATCH"*
> 
> Then, you will get the patch with "[staging/HTTPS-TLS][PATCH]" subject.

I think

  --subject-prefix="staging/HTTPS-TLS PATCH"

should work fine just as well, giving [staging/HTTPS-TLS PATCH].

The bracketed part (a "bag of tags") is a hint that is meant for humans to 
read, and for the patch application tools (like git-am) to throw away. It can 
well carry information (like a staging branch name) beyond "PATCH", "03/12", 
and "v2". For example, you could have

  [staging/HTTPS-TLS PATCH v2 03/12] FooPkg: frob Bar

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

Re: [edk2] [patch] MdeModulePkg/NvmExpressDxe: comments update to meet implementation

[Simon (Xiang) Lian-SSI]

New change looks good to me.
Thanks,
Simon
-Original Message-
From: Wu, Hao A [mailto:hao.a...@intel.com] 
Sent: Tuesday, April 26, 2016 12:05 AM
To: Tian, Feng; edk2-devel@lists.01.org
Cc: Simon (Xiang) Lian-SSI
Subject: RE: [patch] MdeModulePkg/NvmExpressDxe: comments update to meet 
implementation

Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

> -Original Message-
> From: Tian, Feng
> Sent: Tuesday, April 26, 2016 3:01 PM
> To: edk2-devel@lists.01.org
> Cc: Simon Lian-SSI; Wu; Wu, Hao A
> Subject: [patch] MdeModulePkg/NvmExpressDxe: comments update to meet 
> implementation
> 
> Cc: Simon (Xiang) Lian-SSI 
> Cc: Wu, Hao A 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Feng Tian 
> ---
>  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
> index 21c6255..6cbef3e 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
> @@ -2,7 +2,7 @@
>NvmExpressDxe driver is used to manage non-volatile memory 
> subsystem which follows
>NVM Express specification.
> 
> -  Copyright (c) 2013 - 2015, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2013 - 2016, Intel Corporation. All rights 
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of 
> the BSD License
>which accompanies this distribution.  The full text of the license 
> may be found at @@ -101,13 +101,11 @@ struct 
> _NVME_CONTROLLER_PRIVATE_DATA {
>NVME_ADMIN_CONTROLLER_DATA  *ControllerData;
> 
>//
> -  // 6 x 4kB aligned buffers will be carved out of this buffer.
> +  // 4 x 4kB aligned buffers will be carved out of this buffer.
>// 1st 4kB boundary is the start of the admin submission queue.
> -  // 2nd 4kB boundary is the start of the I/O submission queue #1.
> -  // 3rd 4kB boundary is the start of the admin completion queue.
> -  // 4th 4kB boundary is the start of the I/O completion queue #1.
> -  // 5th 4kB boundary is the start of the first PRP list page.
> -  // 6th 4kB boundary is the start of the second PRP list page.
> +  // 2nd 4kB boundary is the start of the admin completion queue.
> +  // 3rd 4kB boundary is the start of I/O submission queue #1.
> +  // 4th 4kB boundary is the start of I/O completion queue #1.
>//
>UINT8   *Buffer;
>UINT8   *BufferPciAddr;
> --
> 2.7.1.windows.2

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

Re: [edk2] [Patch v3 05/23] OvmfPkg: Duplicate PlatformBdsLib to PlatformBootManagerLib

[Laszlo Ersek]

On 04/21/16 08:57, Ruiyu Ni wrote:
> It will be changed to build with MdeModulePkg/BDS.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> ---
>  .../Library/PlatformBootManagerLib/BdsPlatform.c   | 1575 
> 
>  .../Library/PlatformBootManagerLib/BdsPlatform.h   |  292 
>  .../PlatformBootManagerLib/PlatformBdsLib.inf  |   73 +
>  .../Library/PlatformBootManagerLib/PlatformData.c  |   51 +
>  .../Library/PlatformBootManagerLib/QemuKernel.c|  170 +++
>  5 files changed, 2161 insertions(+)
>  create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>  create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
>  create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/PlatformBdsLib.inf
>  create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
>  create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c

According to

  git show --find-copies-harder 7d4750d37fad464f6452190c971f9a7dc6b1ce3e

this creates an identical copy of "OvmfPkg/Library/PlatformBdsLib". I
recommend / request the following:

(1) In this patch,
- create a new FILE_GUID for the INF file immediately,
- update the Intel copyright notice as appropriate.

These changes are already present in patch #7 ("OvmfPkg/PlatformBds:
Follow PlatformBootManagerLib interfaces"), but in my opinion, the new
FILE_GUID and the copyright update belong here, not to patch #7.

(2) For the next two patches:

please squash patch #6 ("OvmfPkg/PlatformBds: Rename INF file") and #7
together.

(
Git handles patches well where a file is renamed and then immediately
modified -- just make sure rename detection is enabled in your git config:

[diff]
renames = copies
)

For the unified patch, the subject line should be

OvmfPkg/PlatformBootManagerLib: Follow PlatformBootManagerLib interfaces

(72 characters).

(3) For the rest of the patches: I believe their subject lines should
refer to "OvmfPkg/PlatformBootManagerLib", not "OvmfPkg/PlatformBds".

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

Re: [edk2] [PATCH 0/2] OvmfPkg: fix use-after-free in SataControllerStop()

[Laszlo Ersek]

On 04/26/16 17:13, Jordan Justen wrote:
> Series Reviewed-by: Jordan Justen 

Thank you, commit range dea0d6bf2f19..0b448dd8b27c.

Laszlo

> On 2016-04-26 05:42:10, Laszlo Ersek wrote:
>> Brown paper bag for Laszlo.
>>
>> Fix tested with repeated connects / disconnects on Q35's PCI dev/fun at
>> 00:1f.2 (onboard SATA controller) in the UEFI shell.
>>
>> Patches formatted with --function-context for better readability.
>>
>> Cc: wang xiaofeng 
>> Cc: Jordan Justen 
>> Cc: Ruiyu Ni 
>>
>> Laszlo Ersek (2):
>>   OvmfPkg: SataControllerDxe: SataControllerStop: remove useless null
>> check
>>   OvmfPkg: SataControllerDxe: SataControllerStop: fix use after free
>>
>>  OvmfPkg/SataControllerDxe/SataController.c | 37 +++-
>>  1 file changed, 20 insertions(+), 17 deletions(-)
>>
>> -- 
>> 1.8.3.1
>>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

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

Re: [edk2] [Patch v3 00/23] Use MdeModulePkg/BDS in OVMF platform

[Laszlo Ersek]

On 04/26/16 17:38, Michael Zimmermann wrote:
> is Intel's bds deprecated now

Yes, it is. I seem to remember that Ray said he wouldn't implement new
UEFI spec features for the BDS driver in IntelFrameworkModulePkg, only
the new one in MdeModulePkg.

IIRC the main reason for the new BDS driver (in MdeModulePkg) is better
separation of responsibilities -- there is now a BDS driver providing
the BDS arch protocol, and a standalone UEFI application that is
responsible for UI etc. As far as I recall anyway.

Thanks
Laszlo

> or what is this switch about?
> 
> Michael
> 
> On Thu, Apr 21, 2016 at 9:03 AM, Ni, Ruiyu  wrote:
> 
>> The changes set can be found in below GIT repos:
>> https://github.com/niruiyu/edk2/tree/Ovmf_Bds2
>>
>>
>> Regards,
>> Ray
>>
>>> -Original Message-
>>> From: Ni, Ruiyu
>>> Sent: Thursday, April 21, 2016 2:58 PM
>>> To: edk2-devel@lists.01.org
>>> Cc: Ni, Ruiyu 
>>> Subject: [Patch v3 00/23] Use MdeModulePkg/BDS in OVMF platform
>>>
>>> The patch serials creates a flag USE_OLD_BDS and by default the value
>>> of the flag is FALSE so that the new MdeModulePkg/BDS is used.
>>> User can define USE_OLD_BDS as TRUE to force to use
>> IntelFrameworkModulePkg
>>> /BDS.
>>>
>>> The v3 adopts comments for v1 and v2 to split the big changes to
>>> small changes and also expose the EfiBootManagerGetLoadOptionBuffer().
>>>
>>> Ruiyu Ni (23):
>>>  MdeModulePkg/UefiBootManagerLib: Expose *GetLoadOptionBuffer() API
>>>  OvmfPkg/PlatformPei: Add memory above 4GB as tested
>>>  OvmfPkg: Duplicate QemuBootOrderLib to QemuNewBootOrderLib
>>>  OvmfPkg/QemuNewBootOrderLib: Build with UefiBootManagerLib
>>>  OvmfPkg: Duplicate PlatformBdsLib to PlatformBootManagerLib
>>>  OvmfPkg/PlatformBds: Rename INF file
>>>  OvmfPkg/PlatformBds: Follow PlatformBootManagerLib interfaces
>>>  OvmfPkg/PlatformBds: use EfiBootManagerUpdateConsoleVariable
>>>  OvmfPkg/PlatformBds: link to UefiBootManagerLib
>>>  OvmfPkg/PlatformBds: Use ConvertDevicePathToText in DevicePathLib
>>>  OvmfPkg/PlatformBds: Initialize console variables in *BeforeConsole()
>>>  OvmfPkg/PlatformBds: Do not launch Boot Manager Menu
>>>  OvmfPkg/PlatformBds: Register boot options and hot keys.
>>>  OvmfPkg/PlatformBds: Remove unused local functions.
>>>  OvmfPkg/PlatformBds: Change PlatformBdsConnectSequence()
>>>  OvmfPkg/PlatformBds: Use EfiBootManagerRefreshAllBootOption()
>>>  OvmfPkg/PlatformBds: Remove PlatformBdsGetDriverOption()
>>>  OvmfPkg/PlatformBds: Use GetBootModeHob() in HobLib
>>>  OvmfPkg/PlatformBds: Remove unnecessary memory test
>>>  OvmfPkg/PlatformBds: Remove unused variables and function prototypes.
>>>  OvmfPkg/PlatformBds: Add EnableQuietBoot and DisableQuietBoot
>>>  OvmfPkg/PlatformBds: Remove unused C structures definitions.
>>>  OvmfPkg: Use MdeModulePkg/BDS
>>>
>>> MdeModulePkg/Include/Library/UefiBootManagerLib.h  |   23 +-
>>> MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |   11 +-
>>> .../Library/UefiBootManagerLib/BmLoadOption.c  |2 +-
>>> .../Library/UefiBootManagerLib/InternalBm.h|   19 -
>>> .../Library/PlatformBootManagerLib/BdsPlatform.c   | 1371 ++
>>> .../Library/PlatformBootManagerLib/BdsPlatform.h   |  246 +++
>>> .../PlatformBootManagerLib.inf |   80 +
>>> .../Library/PlatformBootManagerLib/PlatformData.c  |   41 +
>>> .../Library/PlatformBootManagerLib/QemuKernel.c|  170 ++
>>> OvmfPkg/Library/PlatformBootManagerLib/QuietBoot.c |  668 +++
>>> .../Library/QemuNewBootOrderLib/ExtraRootBusMap.c  |  313 
>>> .../Library/QemuNewBootOrderLib/ExtraRootBusMap.h  |   40 +
>>> .../Library/QemuNewBootOrderLib/QemuBootOrderLib.c | 1913
>> 
>>> .../QemuNewBootOrderLib/QemuBootOrderLib.inf   |   68 +
>>> OvmfPkg/OvmfPkgIa32.dsc|   45 +-
>>> OvmfPkg/OvmfPkgIa32.fdf|5 +
>>> OvmfPkg/OvmfPkgIa32X64.dsc |   47 +-
>>> OvmfPkg/OvmfPkgIa32X64.fdf |5 +
>>> OvmfPkg/OvmfPkgX64.dsc |   45 +-
>>> OvmfPkg/OvmfPkgX64.fdf |5 +
>>> OvmfPkg/PlatformPei/MemDetect.c|4 +-
>>> OvmfPkg/PlatformPei/Platform.c |   29 -
>>> OvmfPkg/PlatformPei/Platform.h |   14 +-
>>> OvmfPkg/PlatformPei/Xen.c  |8 +-
>>> 24 files changed, 5077 insertions(+), 95 deletions(-)
>>> create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>>> create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
>>> create mode 100644
>> OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>>> create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
>>> create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c
>>> create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/QuietBoot.c
>>> create mode 100644 

Re: [edk2] [PATCH v2] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for image verification failures

[Laszlo Ersek]

On 04/26/16 17:22, Cinnamon Shia wrote:
> Add DEBUG messages in DxeImageerificationLib to help debug Secure Boot image 
> verification failures
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Cinnamon Shia 
> Reviewed-by: Samer EL-Haj-Mahmoud 
> ---
>  .../DxeImageVerificationLib.c  | 37 
> +-
>  1 file changed, 36 insertions(+), 1 deletion(-)

... Sorry, I feel quite dumb. :(

I have now actually checked what IsAllowedByDb does, and it says:

  "Check whether the image signature can be verified by the trusted
  certificates in DB database."

In other words, it is not a direct hash match, but a certificate chain
match. So the variable should not be called "SigFoundInDb" after all,
but something like "SigAcceptedByCertsInDb". I feel very bad that I
realized this just now. :(

Another comment:

> diff --git 
> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c 
> b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> index 4b4d3bf..95c0007 100644
> --- a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> +++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> @@ -13,6 +13,7 @@
>untrusted PE/COFF image and validate its data structure within this image 
> buffer before use.
>  
>  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
> +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  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
> @@ -71,6 +72,8 @@ HASH_TABLE mHash[] = {
>{ L"SHA512", 64, [32], 9, Sha512GetContextSize, Sha512Init, 
> Sha512Update, Sha512Final}
>  };
>  
> +EFI_STRING mHashTypeStr;
> +
>  /**
>SecureBoot Hook for processing image verification.
>  
> @@ -340,6 +343,7 @@ HashPeImage (
>  return FALSE;
>}
>  
> +  mHashTypeStr = mHash[HashAlg].Name;
>CtxSize   = mHash[HashAlg].GetContextSize();
>  
>HashCtx = AllocatePool (CtxSize);
> @@ -1782,6 +1786,7 @@ ImageVerificationInAuditMode (
>UINT32   OffSet;
>CHAR16   *FilePathStr;
>UINTNSignatureListSize;
> +  BOOLEAN  SigFoundInDb;
>  
>SignatureList = NULL;
>WinCertificate= NULL;
> @@ -1790,6 +1795,7 @@ ImageVerificationInAuditMode (
>FilePathStr   = NULL;
>Action= EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED | 
> EFI_IMAGE_EXECUTION_INITIALIZED;
>Status= EFI_ACCESS_DENIED;
> +  SigFoundInDb  = FALSE;
>  
>  
>//
> @@ -1873,6 +1879,7 @@ ImageVerificationInAuditMode (
>  //
>  // The information can't be got from the invalid PeImage
>  //
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid. Cannot 
> retrieve image information.\n"));
>  goto END;
>}
>  
> @@ -1896,6 +1903,7 @@ ImageVerificationInAuditMode (
>  //
>  // It is not a valid Pe/Coff file.
>  //
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Not a valid PE/COFF 
> image.\n"));
>  Status = EFI_ACCESS_DENIED;
>  goto END;
>}
> @@ -1942,6 +1950,7 @@ ImageVerificationInAuditMode (
>  // and not be reflected in the security data base "dbx".
>  //
>  if (!HashPeImage (HASHALG_SHA256)) {
> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Failed to hash this 
> image using %s.\n", mHashTypeStr));
>Status = EFI_ACCESS_DENIED;
>goto END;
>  }
> @@ -1955,7 +1964,14 @@ ImageVerificationInAuditMode (
>//
>if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
> mImageDigest, , mImageDigestSize)) {
>  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
> EFI_IMAGE_EXECUTION_INITIALIZED;
> +  } else {
> +//
> +// Image Hash is not in DB/DBX
> +//
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not signed 
> and %s hash of image is not found in DB/DBX.\n", mHashTypeStr));
>}
> +} else {
> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not signed and 
> %s hash of image is rejected by DBX.\n", mHashTypeStr));
>  }
>  
>  //
> @@ -2029,7 +2045,9 @@ ImageVerificationInAuditMode (
>  // Check the digital signature against the valid certificate in allowed 
> database (db).
>  //
>  if (!IsForbiddenByDbx (AuthData, AuthDataSize, TRUE, FilePathStr, File)) 
> {
> -  IsAllowedByDb (AuthData, AuthDataSize, TRUE, FilePathStr, File);
> +  SigFoundInDb = IsAllowedByDb (AuthData, AuthDataSize, TRUE, 
> FilePathStr, File);
> +} else {
> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is signed but 
> signature is rejected by DBX.\n"));
>  }
>  
>  //
> @@ -2038,7 

Re: [edk2] [Patch v3 00/23] Use MdeModulePkg/BDS in OVMF platform

[Michael Zimmermann]

is Intel's bds deprecated now or what is this switch about?

Michael

On Thu, Apr 21, 2016 at 9:03 AM, Ni, Ruiyu  wrote:

> The changes set can be found in below GIT repos:
> https://github.com/niruiyu/edk2/tree/Ovmf_Bds2
>
>
> Regards,
> Ray
>
> >-Original Message-
> >From: Ni, Ruiyu
> >Sent: Thursday, April 21, 2016 2:58 PM
> >To: edk2-devel@lists.01.org
> >Cc: Ni, Ruiyu 
> >Subject: [Patch v3 00/23] Use MdeModulePkg/BDS in OVMF platform
> >
> >The patch serials creates a flag USE_OLD_BDS and by default the value
> >of the flag is FALSE so that the new MdeModulePkg/BDS is used.
> >User can define USE_OLD_BDS as TRUE to force to use
> IntelFrameworkModulePkg
> >/BDS.
> >
> >The v3 adopts comments for v1 and v2 to split the big changes to
> >small changes and also expose the EfiBootManagerGetLoadOptionBuffer().
> >
> >Ruiyu Ni (23):
> >  MdeModulePkg/UefiBootManagerLib: Expose *GetLoadOptionBuffer() API
> >  OvmfPkg/PlatformPei: Add memory above 4GB as tested
> >  OvmfPkg: Duplicate QemuBootOrderLib to QemuNewBootOrderLib
> >  OvmfPkg/QemuNewBootOrderLib: Build with UefiBootManagerLib
> >  OvmfPkg: Duplicate PlatformBdsLib to PlatformBootManagerLib
> >  OvmfPkg/PlatformBds: Rename INF file
> >  OvmfPkg/PlatformBds: Follow PlatformBootManagerLib interfaces
> >  OvmfPkg/PlatformBds: use EfiBootManagerUpdateConsoleVariable
> >  OvmfPkg/PlatformBds: link to UefiBootManagerLib
> >  OvmfPkg/PlatformBds: Use ConvertDevicePathToText in DevicePathLib
> >  OvmfPkg/PlatformBds: Initialize console variables in *BeforeConsole()
> >  OvmfPkg/PlatformBds: Do not launch Boot Manager Menu
> >  OvmfPkg/PlatformBds: Register boot options and hot keys.
> >  OvmfPkg/PlatformBds: Remove unused local functions.
> >  OvmfPkg/PlatformBds: Change PlatformBdsConnectSequence()
> >  OvmfPkg/PlatformBds: Use EfiBootManagerRefreshAllBootOption()
> >  OvmfPkg/PlatformBds: Remove PlatformBdsGetDriverOption()
> >  OvmfPkg/PlatformBds: Use GetBootModeHob() in HobLib
> >  OvmfPkg/PlatformBds: Remove unnecessary memory test
> >  OvmfPkg/PlatformBds: Remove unused variables and function prototypes.
> >  OvmfPkg/PlatformBds: Add EnableQuietBoot and DisableQuietBoot
> >  OvmfPkg/PlatformBds: Remove unused C structures definitions.
> >  OvmfPkg: Use MdeModulePkg/BDS
> >
> > MdeModulePkg/Include/Library/UefiBootManagerLib.h  |   23 +-
> > MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |   11 +-
> > .../Library/UefiBootManagerLib/BmLoadOption.c  |2 +-
> > .../Library/UefiBootManagerLib/InternalBm.h|   19 -
> > .../Library/PlatformBootManagerLib/BdsPlatform.c   | 1371 ++
> > .../Library/PlatformBootManagerLib/BdsPlatform.h   |  246 +++
> > .../PlatformBootManagerLib.inf |   80 +
> > .../Library/PlatformBootManagerLib/PlatformData.c  |   41 +
> > .../Library/PlatformBootManagerLib/QemuKernel.c|  170 ++
> > OvmfPkg/Library/PlatformBootManagerLib/QuietBoot.c |  668 +++
> > .../Library/QemuNewBootOrderLib/ExtraRootBusMap.c  |  313 
> > .../Library/QemuNewBootOrderLib/ExtraRootBusMap.h  |   40 +
> > .../Library/QemuNewBootOrderLib/QemuBootOrderLib.c | 1913
> 
> > .../QemuNewBootOrderLib/QemuBootOrderLib.inf   |   68 +
> > OvmfPkg/OvmfPkgIa32.dsc|   45 +-
> > OvmfPkg/OvmfPkgIa32.fdf|5 +
> > OvmfPkg/OvmfPkgIa32X64.dsc |   47 +-
> > OvmfPkg/OvmfPkgIa32X64.fdf |5 +
> > OvmfPkg/OvmfPkgX64.dsc |   45 +-
> > OvmfPkg/OvmfPkgX64.fdf |5 +
> > OvmfPkg/PlatformPei/MemDetect.c|4 +-
> > OvmfPkg/PlatformPei/Platform.c |   29 -
> > OvmfPkg/PlatformPei/Platform.h |   14 +-
> > OvmfPkg/PlatformPei/Xen.c  |8 +-
> > 24 files changed, 5077 insertions(+), 95 deletions(-)
> > create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> > create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
> > create mode 100644
> OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> > create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
> > create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c
> > create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/QuietBoot.c
> > create mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.c
> > create mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.h
> > create mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.c
> > create mode 100644
> OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.inf
> >
> >--
> >2.7.0.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel 

[edk2] [PATCH v2] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for image verification failures

[Cinnamon Shia]

Add DEBUG messages in DxeImageerificationLib to help debug Secure Boot image 
verification failures

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
Reviewed-by: Samer EL-Haj-Mahmoud 
---
 .../DxeImageVerificationLib.c  | 37 +-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git 
a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c 
b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
index 4b4d3bf..95c0007 100644
--- a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
+++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
@@ -13,6 +13,7 @@
   untrusted PE/COFF image and validate its data structure within this image 
buffer before use.
 
 Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2016 Hewlett Packard Enterprise Development LP
 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
@@ -71,6 +72,8 @@ HASH_TABLE mHash[] = {
   { L"SHA512", 64, [32], 9, Sha512GetContextSize, Sha512Init, 
Sha512Update, Sha512Final}
 };
 
+EFI_STRING mHashTypeStr;
+
 /**
   SecureBoot Hook for processing image verification.
 
@@ -340,6 +343,7 @@ HashPeImage (
 return FALSE;
   }
 
+  mHashTypeStr = mHash[HashAlg].Name;
   CtxSize   = mHash[HashAlg].GetContextSize();
 
   HashCtx = AllocatePool (CtxSize);
@@ -1782,6 +1786,7 @@ ImageVerificationInAuditMode (
   UINT32   OffSet;
   CHAR16   *FilePathStr;
   UINTNSignatureListSize;
+  BOOLEAN  SigFoundInDb;
 
   SignatureList = NULL;
   WinCertificate= NULL;
@@ -1790,6 +1795,7 @@ ImageVerificationInAuditMode (
   FilePathStr   = NULL;
   Action= EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED | 
EFI_IMAGE_EXECUTION_INITIALIZED;
   Status= EFI_ACCESS_DENIED;
+  SigFoundInDb  = FALSE;
 
 
   //
@@ -1873,6 +1879,7 @@ ImageVerificationInAuditMode (
 //
 // The information can't be got from the invalid PeImage
 //
+DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid. Cannot 
retrieve image information.\n"));
 goto END;
   }
 
@@ -1896,6 +1903,7 @@ ImageVerificationInAuditMode (
 //
 // It is not a valid Pe/Coff file.
 //
+DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Not a valid PE/COFF 
image.\n"));
 Status = EFI_ACCESS_DENIED;
 goto END;
   }
@@ -1942,6 +1950,7 @@ ImageVerificationInAuditMode (
 // and not be reflected in the security data base "dbx".
 //
 if (!HashPeImage (HASHALG_SHA256)) {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Failed to hash this image 
using %s.\n", mHashTypeStr));
   Status = EFI_ACCESS_DENIED;
   goto END;
 }
@@ -1955,7 +1964,14 @@ ImageVerificationInAuditMode (
   //
   if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
mImageDigest, , mImageDigestSize)) {
 Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
EFI_IMAGE_EXECUTION_INITIALIZED;
+  } else {
+//
+// Image Hash is not in DB/DBX
+//
+DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not signed and 
%s hash of image is not found in DB/DBX.\n", mHashTypeStr));
   }
+} else {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not signed and 
%s hash of image is rejected by DBX.\n", mHashTypeStr));
 }
 
 //
@@ -2029,7 +2045,9 @@ ImageVerificationInAuditMode (
 // Check the digital signature against the valid certificate in allowed 
database (db).
 //
 if (!IsForbiddenByDbx (AuthData, AuthDataSize, TRUE, FilePathStr, File)) {
-  IsAllowedByDb (AuthData, AuthDataSize, TRUE, FilePathStr, File);
+  SigFoundInDb = IsAllowedByDb (AuthData, AuthDataSize, TRUE, FilePathStr, 
File);
+} else {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is signed but 
signature is rejected by DBX.\n"));
 }
 
 //
@@ -2038,7 +2056,13 @@ ImageVerificationInAuditMode (
 if (!IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE1, 
mImageDigest, , mImageDigestSize)) {
   if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
mImageDigest, , mImageDigestSize)) {
 Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
EFI_IMAGE_EXECUTION_INITIALIZED; 
+  } else {
+if (SigFoundInDb) {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is signed but 
signature and %s hash of image are not found in DB/DBX.\n", mHashTypeStr));
+}
   }
+} else {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is signed but %s 
hash of image is rejected by DBX.\n", mHashTypeStr));
 }
 
 //
@@ -2259,6 +2283,7 @@ 

Re: [edk2] [Patch v3 06/23] OvmfPkg/PlatformBds: Rename INF file

[Laszlo Ersek]

On 04/21/16 08:57, Ruiyu Ni wrote:
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> ---
>  .../PlatformBootManagerLib/PlatformBdsLib.inf  | 73 
> --
>  .../PlatformBootManagerLib.inf | 73 
> ++
>  2 files changed, 73 insertions(+), 73 deletions(-)
>  delete mode 100644 OvmfPkg/Library/PlatformBootManagerLib/PlatformBdsLib.inf
>  create mode 100644 
> OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf

With rename detection enabled, this patch is shown as:

> commit dfe42c6b2b8a36abfb2aae5fdd3fa0aae8382bea
> Author: Ruiyu Ni 
> Date:   Wed Apr 20 15:46:46 2016 +0800
> 
> OvmfPkg/PlatformBds: Rename INF file
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> 
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBdsLib.inf 
> b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> similarity index 100%
> rename from OvmfPkg/Library/PlatformBootManagerLib/PlatformBdsLib.inf
> rename to OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf

It's good, but as I requested in my patch #5 comments, please squash this one 
into patch #7.

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

Re: [edk2] [PATCH] MdeModulePkg/TerminalDxe: Set polling rate by serial IO mode

[Heyi Guo]

Hi Michael,

It seems we are making the implementation more and more complicated. How 
about just creating a PCD for polling rate which can be set freely by 
platforms?


Regards.

Heyi

On 04/24/2016 12:11 AM, Kinney, Michael D wrote:

Heyi Guo,

The TerminalDxe driver is intended to be a UEFI Driver.  The Timer Arch 
Protocol is
a PI Protocol that is intended to be used by the PI DXE Core.  In order to 
determine
the timer rate in a UEFI way, create a periodic timer event with a period of 1, 
100ns
unit, and then measure the time between timer event notification functions.

Mike


-Original Message-
From: Heyi Guo [mailto:heyi@linaro.org]
Sent: Saturday, April 23, 2016 1:54 AM
To: edk2-devel@lists.01.org
Cc: Heyi Guo ; Tian, Feng ; Zeng, Star
; Kinney, Michael D 
Subject: [edk2] [PATCH] MdeModulePkg/TerminalDxe: Set polling rate by serial IO 
mode

Calculate serial input polling rate according to parameters from
serial IO mode as below, to fix potential input truncation.

Polling interval (100ns) =
FifoDepth * (StartBit + DataBits + StopBits + ParityBits) * 10,000,000
/ BaudRate
(StopBits is assumed to be 1 and ParityBits is ignored for simplicity.

However, as the event is time sensitive, we need to align the interval
to timer interrupt period to make sure the event will be triggered at
the expected rate. E.g. if the interval is 2.7ms and timer interrupt
period is 1ms, the event will be triggered by time slice sequence as
below:
3ms 3ms 2ms 3ms 3ms 2ms...

In such case we will adjust the polling interval to be 2ms.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo 
Cc: Feng Tian 
Cc: Star Zeng 
Cc: Michael D Kinney 
---
  .../Universal/Console/TerminalDxe/Terminal.c   |  5 +-
  .../Universal/Console/TerminalDxe/Terminal.h   | 28 ++-
  .../Universal/Console/TerminalDxe/TerminalConIn.c  | 92 ++
  .../Universal/Console/TerminalDxe/TerminalDxe.inf  |  1 +
  4 files changed, 123 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
index 6fde3b2..2944707 100644
--- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
+++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
@@ -71,6 +71,7 @@ TERMINAL_DEV  mTerminalDevTemplate = {
},
NULL, // TerminalConsoleModeData
0,  // SerialInTimeOut
+  0,  // KeyboardTimerInterval

NULL, // RawFifo
NULL, // UnicodeFiFo
@@ -984,10 +985,12 @@ TerminalDriverBindingStart (
  );
  ASSERT_EFI_ERROR (Status);

+TerminalDevice->KeyboardTimerInterval = GetKeyboardTimerInterval (Mode);
+
  Status = gBS->SetTimer (
  TerminalDevice->TimerEvent,
  TimerPeriodic,
-KEYBOARD_TIMER_INTERVAL
+TerminalDevice->KeyboardTimerInterval
  );
  ASSERT_EFI_ERROR (Status);

diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
index 269d2ae..a1ff595 100644
--- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
+++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
@@ -28,6 +28,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS
OR IMPLIED.
  #include 
  #include 
  #include 
+#include 

  #include 
  #include 
@@ -68,8 +69,6 @@ typedef struct {
UINTN   Rows;
  } TERMINAL_CONSOLE_MODE_DATA;

-#define KEYBOARD_TIMER_INTERVAL 20  // 0.02s
-
  #define TERMINAL_DEV_SIGNATURE  SIGNATURE_32 ('t', 'm', 'n', 'l')

  #define TERMINAL_CONSOLE_IN_EX_NOTIFY_SIGNATURE SIGNATURE_32 ('t', 'm', 'e', 
'n')
@@ -91,6 +90,7 @@ typedef struct {
EFI_SIMPLE_TEXT_OUTPUT_MODE SimpleTextOutputMode;
TERMINAL_CONSOLE_MODE_DATA  *TerminalConsoleModeData;
UINTN   SerialInTimeOut;
+  UINT64  KeyboardTimerInterval;
RAW_DATA_FIFO   *RawFiFo;
UNICODE_FIFO*UnicodeFiFo;
EFI_KEY_FIFO*EfiKeyFiFo;
@@ -1358,4 +1358,28 @@ TerminalConInTimerHandler (
IN EFI_EVENTEvent,
IN VOID *Context
);
+
+/**
+  Calculate input polling timer interval by serial IO mode.
+
+  @param  Mode  Pointer to serial IO mode.
+
+  @retval The required polling timer interval in 100ns.
+
+**/
+UINT64
+GetKeyboardTimerInterval (
+  IN EFI_SERIAL_IO_MODE   *Mode
+  );
+
+/**
+  Update period of polling timer event.
+
+  @param  TerminalDeviceThe terminal device to update.
+**/
+VOID
+UpdatePollingRate (
+  IN TERMINAL_DEV *TerminalDevice
+  );
+
  #endif
diff --git 

Re: [edk2] [PATCH 0/2] OvmfPkg: fix use-after-free in SataControllerStop()

[Jordan Justen]

Series Reviewed-by: Jordan Justen 

On 2016-04-26 05:42:10, Laszlo Ersek wrote:
> Brown paper bag for Laszlo.
> 
> Fix tested with repeated connects / disconnects on Q35's PCI dev/fun at
> 00:1f.2 (onboard SATA controller) in the UEFI shell.
> 
> Patches formatted with --function-context for better readability.
> 
> Cc: wang xiaofeng 
> Cc: Jordan Justen 
> Cc: Ruiyu Ni 
> 
> Laszlo Ersek (2):
>   OvmfPkg: SataControllerDxe: SataControllerStop: remove useless null
> check
>   OvmfPkg: SataControllerDxe: SataControllerStop: fix use after free
> 
>  OvmfPkg/SataControllerDxe/SataController.c | 37 +++-
>  1 file changed, 20 insertions(+), 17 deletions(-)
> 
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v3 04/23] OvmfPkg/QemuNewBootOrderLib: Build with UefiBootManagerLib

[Laszlo Ersek]

This patch looks very good, I have a few minor comments.

(Sorry that I'm taking so long to review individual patches -- reviewing this 
one, and writing up my comments for it, took me two hours, for example. I'm 
trying to be thorough.)

On 04/21/16 08:57, Ruiyu Ni wrote:
> NOTE: SetBootOrderFromQemu() interface is not changed.
> But when the old IntelFrameworkModulePkg/BDS is no longer used in
> OVMF and ArmVirtPkg, additional patch will be submitted to change
> this interface to remove parameter BootOptionList.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> ---
>  .../Library/QemuNewBootOrderLib/QemuBootOrderLib.c | 134 
> -
>  .../QemuNewBootOrderLib/QemuBootOrderLib.inf   |   4 +-
>  2 files changed, 80 insertions(+), 58 deletions(-)
> 
> diff --git a/OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.c 
> b/OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.c
> index 15065b7..f015422 100644
> --- a/OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.c
> +++ b/OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.c
> @@ -2,7 +2,7 @@
>Rewrite the BootOrder NvVar based on QEMU's "bootorder" fw_cfg file.
>  
>Copyright (C) 2012 - 2014, Red Hat, Inc.
> -  Copyright (c) 2013, Intel Corporation. All rights reserved.
> +  Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
>  
>This program and the accompanying materials are licensed and made available
>under the terms and conditions of the BSD License which accompanies this
> @@ -13,10 +13,11 @@
>WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
>  **/
>  
> +#include 

(1) Why is this protocol include necessary?

>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -253,8 +254,10 @@ typedef struct {
>LOAD_OPTION_ACTIVE attribute.
>  **/
>  typedef struct {
> -  CONST BDS_COMMON_OPTION *BootOption; // reference only, no ownership
> -  BOOLEAN Appended;// has been added to a BOOT_ORDER?
> +  CONST EFI_BOOT_MANAGER_LOAD_OPTION *BootOption; // reference only, no
> +  //   ownership
> +  BOOLEANAppended;// has been added to a
> +  //   BOOT_ORDER?
>  } ACTIVE_OPTION;
>  
>  
> @@ -300,7 +303,7 @@ BootOrderAppend (
>}
>  
>BootOrder->Data[BootOrder->Produced++] =
> - 
> ActiveOption->BootOption->BootCurrent;
> +   (UINT16) 
> ActiveOption->BootOption->OptionNumber;

I remember that BDS_COMMON_OPTION.OptionNumber also exists, but it wasn't doing 
the right thing; I had to use BootCurrent.

I briefly checked EFI_BOOT_MANAGER_LOAD_OPTION.OptionNumber, and apparently it 
should do the right thing -- tell us what Boot the boot option comes from.

(2) Can you please confirm that?

>ActiveOption->Appended = TRUE;
>return RETURN_SUCCESS;
>  }
> @@ -310,14 +313,16 @@ BootOrderAppend (
>  
>Create an array of ACTIVE_OPTION elements for a boot option list.

(3) Please update the heading to say "boot option array".

> -  @param[in]  BootOptionList  A boot option list, created with
> -  BdsLibEnumerateAllBootOption().
> +  @param[in]  BootOptions  A boot option array, created by
> +   EfiBootManagerGetLoadOptions ().

Hmm, this is not (entirely) correct.

I understand that technically, the boot option array will be created for this 
function with EfiBootManagerGetLoadOptions(). So that part of the comment is 
okay.

However, it is important to document that the boot option array passed to this 
function must be complete -- in other words, it must contain the output of 
full, automatic boot option generation.

The point is that QemuBootOrderLib can only filter out and reorder boot 
options; it cannot create boot options. It relies on the generic BDS library to 
auto-generate all possible boot options (for example, for new virtual devices 
that have been configured since the last run of the virtual machine). Then it 
will decide, case-by-case, whether each of those auto-generated boot options 
should be preserved (and at what position), or removed.

At the moment, we have the following call chain:

BdsEntry() 
[IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c]
  // create empty list
  InitializeListHead ()

  PlatformBdsPolicyBehavior()  
[OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
BdsLibConnectAll() 
[IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConnect.c]
BdsLibEnumerateAllBootOption() 
[IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]

// at this point, BootOptionList
// ends with the auto-generated

Re: [edk2] [PATCH] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for image verification failures

[Shia, Cinnamon]

Make sense to me. Will fix it in the patch v2.

Thanks,
Cinnamon Shia

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, April 26, 2016 9:27 PM
To: Shia, Cinnamon ; edk2-de...@ml01.01.org
Cc: El-Haj-Mahmoud, Samer ; chao.b.zh...@intel.com
Subject: Re: [edk2] [PATCH] SecurityPkg/DxeImageVerificationLib: Add DEBUG 
messages for image verification failures

On 04/26/16 15:10, Shia, Cinnamon wrote:
> Hi Lazlo,
> 
> Thanks for your feedbacks.
> 
> How VerifyStatus being used in ImageVerificationInAuditMode() is from 
> DxeImageVerificationHandler(). Not 100% the same, but similar.

Yes, that's why I got confused initially about it; I recalled the name.

However, it doesn't change the fact that VerifyStatus is not initialized, and 
not assigned unconditionally. It is only assigned conditionally, and then it is 
checked.

> Changing its type to BOOLEAN sounds good to me, do we need to change its name 
> from VerifyStatus to SigFoundInDb to match its type?

I think SigFoundInDb would be a good name indeed.

(The type change and the name change are motivated by the need for 
initialization -- it is easier to assign FALSE to SigFoundInDb unconditionally, 
near the top, than to find some initial EFI_ value for VerifyStatus.)

Thanks
Laszlo

> 
> Thanks,
> Cinnamon Shia
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, April 26, 2016 7:10 PM
> To: Shia, Cinnamon ; edk2-de...@ml01.01.org
> Cc: El-Haj-Mahmoud, Samer ; 
> chao.b.zh...@intel.com
> Subject: Re: [edk2] [PATCH] SecurityPkg/DxeImageVerificationLib: Add 
> DEBUG messages for image verification failures
> 
> On 04/26/16 13:04, Laszlo Ersek wrote:
>> On 04/26/16 09:02, Cinnamon Shia wrote:
>>> Add DEBUG messages in DxeImageerificationLib to help debug Secure 
>>> Boot image verification failures
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Cinnamon Shia 
>>> Reviewed-by: Samer EL-Haj-Mahmoud 
>>> ---
>>>  .../DxeImageVerificationLib.c  | 38 
>>> +-
>>>  1 file changed, 37 insertions(+), 1 deletion(-)
>>>
>>> diff --git
>>> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLi
>>> b
>>> .c
>>> b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLi
>>> b
>>> .c
>>> index 4b4d3bf..4322aac 100644
>>> ---
>>> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLi
>>> b
>>> .c
>>> +++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificati
>>> +++ o
>>> +++ nLib.c
>>> @@ -13,6 +13,7 @@
>>>untrusted PE/COFF image and validate its data structure within this 
>>> image buffer before use.
>>>  
>>>  Copyright (c) 2009 - 2015, Intel Corporation. All rights 
>>> reserved.
>>> +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
>>>  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 @@ -71,6 +72,8 @@ HASH_TABLE mHash[] = {
>>>{ L"SHA512", 64, [32], 9, Sha512GetContextSize, 
>>> Sha512Init, Sha512Update, Sha512Final}  };
>>>  
>>> +EFI_STRING mHashTypeStr;
>>> +
>>>  /**
>>>SecureBoot Hook for processing image verification.
>>>  
>>> @@ -340,6 +343,7 @@ HashPeImage (
>>>  return FALSE;
>>>}
>>>  
>>> +  mHashTypeStr = mHash[HashAlg].Name;
>>>CtxSize   = mHash[HashAlg].GetContextSize();
>>>  
>>>HashCtx = AllocatePool (CtxSize); @@ -1782,6 +1786,7 @@ 
>>> ImageVerificationInAuditMode (
>>>UINT32   OffSet;
>>>CHAR16   *FilePathStr;
>>>UINTNSignatureListSize;
>>> +  EFI_STATUS   VerifyStatus;
>>>  
>>>SignatureList = NULL;
>>>WinCertificate= NULL;
>>> @@ -1873,6 +1878,7 @@ ImageVerificationInAuditMode (
>>>  //
>>>  // The information can't be got from the invalid PeImage
>>>  //
>>> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid. 
>>> + Cannot retrieve image information.\n"));
>>>  goto END;
>>>}
>>>  
>>> @@ -1896,6 +1902,7 @@ ImageVerificationInAuditMode (
>>>  //
>>>  // It is not a valid Pe/Coff file.
>>>  //
>>> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Not a valid 
>>> + PE/COFF image.\n"));
>>>  Status = EFI_ACCESS_DENIED;
>>>  goto END;
>>>}
>>> @@ -1942,6 +1949,7 @@ ImageVerificationInAuditMode (
>>>  // and not be reflected in the security data base "dbx".
>>>  //
>>>  if (!HashPeImage (HASHALG_SHA256)) {
>>> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Failed to hash 
>>> + this image using %s.\n", mHashTypeStr));
>>>Status = EFI_ACCESS_DENIED;
>>>goto 

Re: [edk2] [PATCH] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for image verification failures

[Laszlo Ersek]

On 04/26/16 15:10, Shia, Cinnamon wrote:
> Hi Lazlo,
> 
> Thanks for your feedbacks.
> 
> How VerifyStatus being used in ImageVerificationInAuditMode() is from 
> DxeImageVerificationHandler(). Not 100% the same, but similar.

Yes, that's why I got confused initially about it; I recalled the name.

However, it doesn't change the fact that VerifyStatus is not
initialized, and not assigned unconditionally. It is only assigned
conditionally, and then it is checked.

> Changing its type to BOOLEAN sounds good to me, do we need to change its name 
> from VerifyStatus to SigFoundInDb to match its type?

I think SigFoundInDb would be a good name indeed.

(The type change and the name change are motivated by the need for
initialization -- it is easier to assign FALSE to SigFoundInDb
unconditionally, near the top, than to find some initial EFI_ value
for VerifyStatus.)

Thanks
Laszlo

> 
> Thanks,
> Cinnamon Shia
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Tuesday, April 26, 2016 7:10 PM
> To: Shia, Cinnamon ; edk2-de...@ml01.01.org
> Cc: El-Haj-Mahmoud, Samer ; 
> chao.b.zh...@intel.com
> Subject: Re: [edk2] [PATCH] SecurityPkg/DxeImageVerificationLib: Add DEBUG 
> messages for image verification failures
> 
> On 04/26/16 13:04, Laszlo Ersek wrote:
>> On 04/26/16 09:02, Cinnamon Shia wrote:
>>> Add DEBUG messages in DxeImageerificationLib to help debug Secure 
>>> Boot image verification failures
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Cinnamon Shia 
>>> Reviewed-by: Samer EL-Haj-Mahmoud 
>>> ---
>>>  .../DxeImageVerificationLib.c  | 38 
>>> +-
>>>  1 file changed, 37 insertions(+), 1 deletion(-)
>>>
>>> diff --git 
>>> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib
>>> .c 
>>> b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib
>>> .c
>>> index 4b4d3bf..4322aac 100644
>>> --- 
>>> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib
>>> .c
>>> +++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificatio
>>> +++ nLib.c
>>> @@ -13,6 +13,7 @@
>>>untrusted PE/COFF image and validate its data structure within this 
>>> image buffer before use.
>>>  
>>>  Copyright (c) 2009 - 2015, Intel Corporation. All rights 
>>> reserved.
>>> +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
>>>  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 @@ -71,6 +72,8 @@ HASH_TABLE mHash[] = {
>>>{ L"SHA512", 64, [32], 9, Sha512GetContextSize, 
>>> Sha512Init, Sha512Update, Sha512Final}  };
>>>  
>>> +EFI_STRING mHashTypeStr;
>>> +
>>>  /**
>>>SecureBoot Hook for processing image verification.
>>>  
>>> @@ -340,6 +343,7 @@ HashPeImage (
>>>  return FALSE;
>>>}
>>>  
>>> +  mHashTypeStr = mHash[HashAlg].Name;
>>>CtxSize   = mHash[HashAlg].GetContextSize();
>>>  
>>>HashCtx = AllocatePool (CtxSize);
>>> @@ -1782,6 +1786,7 @@ ImageVerificationInAuditMode (
>>>UINT32   OffSet;
>>>CHAR16   *FilePathStr;
>>>UINTNSignatureListSize;
>>> +  EFI_STATUS   VerifyStatus;
>>>  
>>>SignatureList = NULL;
>>>WinCertificate= NULL;
>>> @@ -1873,6 +1878,7 @@ ImageVerificationInAuditMode (
>>>  //
>>>  // The information can't be got from the invalid PeImage
>>>  //
>>> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid. 
>>> + Cannot retrieve image information.\n"));
>>>  goto END;
>>>}
>>>  
>>> @@ -1896,6 +1902,7 @@ ImageVerificationInAuditMode (
>>>  //
>>>  // It is not a valid Pe/Coff file.
>>>  //
>>> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Not a valid 
>>> + PE/COFF image.\n"));
>>>  Status = EFI_ACCESS_DENIED;
>>>  goto END;
>>>}
>>> @@ -1942,6 +1949,7 @@ ImageVerificationInAuditMode (
>>>  // and not be reflected in the security data base "dbx".
>>>  //
>>>  if (!HashPeImage (HASHALG_SHA256)) {
>>> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Failed to hash 
>>> + this image using %s.\n", mHashTypeStr));
>>>Status = EFI_ACCESS_DENIED;
>>>goto END;
>>>  }
>>> @@ -1955,7 +1963,14 @@ ImageVerificationInAuditMode (
>>>//
>>>if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
>>> mImageDigest, , mImageDigestSize)) {
>>>  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
>>> EFI_IMAGE_EXECUTION_INITIALIZED;
>>> +  } else {
>>> +//
>>> +// Image Hash is not in DB/DBX
>>> +//
>>> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not 
>>> 

Re: [edk2] [PATCH] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for image verification failures

[Shia, Cinnamon]

Hi Lazlo,

Thanks for your feedbacks.

How VerifyStatus being used in ImageVerificationInAuditMode() is from 
DxeImageVerificationHandler(). Not 100% the same, but similar.
Changing its type to BOOLEAN sounds good to me, do we need to change its name 
from VerifyStatus to SigFoundInDb to match its type?

Thanks,
Cinnamon Shia

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, April 26, 2016 7:10 PM
To: Shia, Cinnamon ; edk2-de...@ml01.01.org
Cc: El-Haj-Mahmoud, Samer ; chao.b.zh...@intel.com
Subject: Re: [edk2] [PATCH] SecurityPkg/DxeImageVerificationLib: Add DEBUG 
messages for image verification failures

On 04/26/16 13:04, Laszlo Ersek wrote:
> On 04/26/16 09:02, Cinnamon Shia wrote:
>> Add DEBUG messages in DxeImageerificationLib to help debug Secure 
>> Boot image verification failures
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Cinnamon Shia 
>> Reviewed-by: Samer EL-Haj-Mahmoud 
>> ---
>>  .../DxeImageVerificationLib.c  | 38 
>> +-
>>  1 file changed, 37 insertions(+), 1 deletion(-)
>>
>> diff --git 
>> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib
>> .c 
>> b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib
>> .c
>> index 4b4d3bf..4322aac 100644
>> --- 
>> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib
>> .c
>> +++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificatio
>> +++ nLib.c
>> @@ -13,6 +13,7 @@
>>untrusted PE/COFF image and validate its data structure within this image 
>> buffer before use.
>>  
>>  Copyright (c) 2009 - 2015, Intel Corporation. All rights 
>> reserved.
>> +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
>>  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 @@ -71,6 +72,8 @@ HASH_TABLE mHash[] = {
>>{ L"SHA512", 64, [32], 9, Sha512GetContextSize, 
>> Sha512Init, Sha512Update, Sha512Final}  };
>>  
>> +EFI_STRING mHashTypeStr;
>> +
>>  /**
>>SecureBoot Hook for processing image verification.
>>  
>> @@ -340,6 +343,7 @@ HashPeImage (
>>  return FALSE;
>>}
>>  
>> +  mHashTypeStr = mHash[HashAlg].Name;
>>CtxSize   = mHash[HashAlg].GetContextSize();
>>  
>>HashCtx = AllocatePool (CtxSize);
>> @@ -1782,6 +1786,7 @@ ImageVerificationInAuditMode (
>>UINT32   OffSet;
>>CHAR16   *FilePathStr;
>>UINTNSignatureListSize;
>> +  EFI_STATUS   VerifyStatus;
>>  
>>SignatureList = NULL;
>>WinCertificate= NULL;
>> @@ -1873,6 +1878,7 @@ ImageVerificationInAuditMode (
>>  //
>>  // The information can't be got from the invalid PeImage
>>  //
>> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid. 
>> + Cannot retrieve image information.\n"));
>>  goto END;
>>}
>>  
>> @@ -1896,6 +1902,7 @@ ImageVerificationInAuditMode (
>>  //
>>  // It is not a valid Pe/Coff file.
>>  //
>> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Not a valid 
>> + PE/COFF image.\n"));
>>  Status = EFI_ACCESS_DENIED;
>>  goto END;
>>}
>> @@ -1942,6 +1949,7 @@ ImageVerificationInAuditMode (
>>  // and not be reflected in the security data base "dbx".
>>  //
>>  if (!HashPeImage (HASHALG_SHA256)) {
>> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Failed to hash 
>> + this image using %s.\n", mHashTypeStr));
>>Status = EFI_ACCESS_DENIED;
>>goto END;
>>  }
>> @@ -1955,7 +1963,14 @@ ImageVerificationInAuditMode (
>>//
>>if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
>> mImageDigest, , mImageDigestSize)) {
>>  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
>> EFI_IMAGE_EXECUTION_INITIALIZED;
>> +  } else {
>> +//
>> +// Image Hash is not in DB/DBX
>> +//
>> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not 
>> + signed and %s hash of image is not found in DB/DBX.\n", 
>> + mHashTypeStr));
>>}
>> +} else {
>> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not 
>> + signed and %s hash of image is rejected by DBX.\n", mHashTypeStr));
>>  }
>>  
>>  //
>> @@ -2029,7 +2044,11 @@ ImageVerificationInAuditMode (
>>  // Check the digital signature against the valid certificate in allowed 
>> database (db).
>>  //
>>  if (!IsForbiddenByDbx (AuthData, AuthDataSize, TRUE, FilePathStr, 
>> File)) {
>> -  IsAllowedByDb (AuthData, AuthDataSize, TRUE, FilePathStr, File);
>> +  if (IsAllowedByDb (AuthData, AuthDataSize, TRUE, FilePathStr, File)) {
>> +VerifyStatus 

Re: [edk2] [Patch v3 03/23] OvmfPkg: Duplicate QemuBootOrderLib to QemuNewBootOrderLib

[Laszlo Ersek]

On 04/21/16 08:57, Ruiyu Ni wrote:
> QemuNewBootOrderLib will be changed to work with MdeModulePkg/BDS.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> ---
>  .../Library/QemuNewBootOrderLib/ExtraRootBusMap.c  |  313 
>  .../Library/QemuNewBootOrderLib/ExtraRootBusMap.h  |   40 +
>  .../Library/QemuNewBootOrderLib/QemuBootOrderLib.c | 1891 
> 
>  .../QemuNewBootOrderLib/QemuBootOrderLib.inf   |   68 +
>  4 files changed, 2312 insertions(+)
>  create mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.c
>  create mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.h
>  create mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.c
>  create mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.inf

For patch series that contain patches like this, it usually helps both the 
author and the reviewer(s) if the series is formatted with the option 
"--find-copies-harder".

For example, using your branch, the command

  git show --find-copies-harder ca5ee43c3ed952b8c846819dfc2cf9c963d13641

generates the following output:

> commit ca5ee43c3ed952b8c846819dfc2cf9c963d13641
> Author: Ruiyu Ni 
> Date:   Fri Apr 15 18:19:29 2016 +0800
>
> OvmfPkg: Duplicate QemuBootOrderLib to QemuNewBootOrderLib
>
> QemuNewBootOrderLib will be changed to work with MdeModulePkg/BDS.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
>
> diff --git a/OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.c 
> b/OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.c
> similarity index 100%
> copy from OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.c
> copy to OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.c
> diff --git a/OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.h 
> b/OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.h
> similarity index 100%
> copy from OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.h
> copy to OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.h
> diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c 
> b/OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.c
> similarity index 100%
> copy from OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
> copy to OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.c
> diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf 
> b/OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.inf
> similarity index 100%
> copy from OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> copy to OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.inf

In other words, QemuNewBootOrderLib is an identical copy of QemuBootOrderLib.

When I do this kind of library instance duplication, I usually modify the 
FILE_GUID in the INF file immediately (so that no duplicate FILE_GUID exists in 
the tree at any stage).

I checked the FILE_GUID in 
"OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.inf" at the end of your 
series as well, and it is unchanged (4FFFA9E1-103D-4CF2-9C06-563BDD03050E). 
Thus, please generate a new FILE_GUID with "uuidgen", and squash that change 
into this patch.

Further changes to be squashed into this patch:
- you might want to update the Intel copyright notice in the INF file,
- BASE_NAME should be updated to QemuNewBootOrderLib.

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

[edk2] [PATCH 2/2] OvmfPkg: SataControllerDxe: SataControllerStop: fix use after free

[Laszlo Ersek]

It would be possible to remove the UAF without local variables, by calling
SataPrivateData->PciIo->Attributes() before releasing SataPrivateData.

However, by keeping the location of the call (for which temporary
variables are necessary), we continue to match the error path logic in
SataControllerStart(), which is always recommended.

Reported-by: wang xiaofeng 
Fixes: bcab71413407e61c144994925556725dd65eede9
Cc: wang xiaofeng 
Cc: Jordan Justen 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/SataControllerDxe/SataController.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/OvmfPkg/SataControllerDxe/SataController.c 
b/OvmfPkg/SataControllerDxe/SataController.c
index e5ee63a0ab63..1f84ad034e5b 100644
--- a/OvmfPkg/SataControllerDxe/SataController.c
+++ b/OvmfPkg/SataControllerDxe/SataController.c
@@ -563,90 +563,95 @@ EFIAPI
 SataControllerStop (
   IN EFI_DRIVER_BINDING_PROTOCOL*This,
   IN EFI_HANDLE Controller,
   IN UINTN  NumberOfChildren,
   IN EFI_HANDLE *ChildHandleBuffer
   )
 {
   EFI_STATUSStatus;
   EFI_IDE_CONTROLLER_INIT_PROTOCOL  *IdeInit;
   EFI_SATA_CONTROLLER_PRIVATE_DATA  *SataPrivateData;
+  EFI_PCI_IO_PROTOCOL   *PciIo;
+  UINT64OriginalPciAttributes;
 
   //
   // Open the produced protocol
   //
   Status = gBS->OpenProtocol (
   Controller,
   ,
   (VOID **) ,
   This->DriverBindingHandle,
   Controller,
   EFI_OPEN_PROTOCOL_GET_PROTOCOL
   );
   if (EFI_ERROR (Status)) {
 return EFI_UNSUPPORTED;
   }
 
   SataPrivateData = SATA_CONTROLLER_PRIVATE_DATA_FROM_THIS (IdeInit);
   ASSERT (SataPrivateData != NULL);
 
+  PciIo = SataPrivateData->PciIo;
+  OriginalPciAttributes = SataPrivateData->OriginalPciAttributes;
+
   //
   // Uninstall the IDE Controller Init Protocol from this instance
   //
   Status = gBS->UninstallMultipleProtocolInterfaces (
   Controller,
   ,
   &(SataPrivateData->IdeInit),
   NULL
   );
   if (EFI_ERROR (Status)) {
 return Status;
   }
 
   if (SataPrivateData->DisqualifiedModes != NULL) {
 FreePool (SataPrivateData->DisqualifiedModes);
   }
   if (SataPrivateData->IdentifyData != NULL) {
 FreePool (SataPrivateData->IdentifyData);
   }
   if (SataPrivateData->IdentifyValid != NULL) {
 FreePool (SataPrivateData->IdentifyValid);
   }
   FreePool (SataPrivateData);
 
   //
   // Restore original PCI attributes
   //
-  SataPrivateData->PciIo->Attributes (
-SataPrivateData->PciIo,
-EfiPciIoAttributeOperationSet,
-SataPrivateData->OriginalPciAttributes,
-NULL
-);
+  PciIo->Attributes (
+   PciIo,
+   EfiPciIoAttributeOperationSet,
+   OriginalPciAttributes,
+   NULL
+   );
 
   //
   // Close protocols opened by Sata Controller driver
   //
   return gBS->CloseProtocol (
 Controller,
 ,
 This->DriverBindingHandle,
 Controller
 );
 }
 
 /**
   Calculate the flat array subscript of a (Channel, Device) pair.
 
   @param[in] SataPrivateData  The private data structure corresponding to the
   SATA controller that attaches the device for
   which the flat array subscript is being
   calculated.
 
   @param[in] Channel  The channel (ie. port) number on the SATA
   controller that the device is attached to.
 
   @param[in] Device   The device number on the channel.
 
   @return  The flat array subscript suitable for indexing DisqualifiedModes,
IdentifyData, and IdentifyValid.
 **/
-- 
1.8.3.1

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

[edk2] [PATCH 0/2] OvmfPkg: fix use-after-free in SataControllerStop()

[Laszlo Ersek]

Brown paper bag for Laszlo.

Fix tested with repeated connects / disconnects on Q35's PCI dev/fun at
00:1f.2 (onboard SATA controller) in the UEFI shell.

Patches formatted with --function-context for better readability.

Cc: wang xiaofeng 
Cc: Jordan Justen 
Cc: Ruiyu Ni 

Laszlo Ersek (2):
  OvmfPkg: SataControllerDxe: SataControllerStop: remove useless null
check
  OvmfPkg: SataControllerDxe: SataControllerStop: fix use after free

 OvmfPkg/SataControllerDxe/SataController.c | 37 +++-
 1 file changed, 20 insertions(+), 17 deletions(-)

-- 
1.8.3.1

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

[edk2] [PATCH 1/2] OvmfPkg: SataControllerDxe: SataControllerStop: remove useless null check

[Laszlo Ersek]

"ASSERT (SataPrivateData != NULL)" is just a few lines higher up.

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/SataControllerDxe/SataController.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/OvmfPkg/SataControllerDxe/SataController.c 
b/OvmfPkg/SataControllerDxe/SataController.c
index ba21717cad81..e5ee63a0ab63 100644
--- a/OvmfPkg/SataControllerDxe/SataController.c
+++ b/OvmfPkg/SataControllerDxe/SataController.c
@@ -563,92 +563,90 @@ EFIAPI
 SataControllerStop (
   IN EFI_DRIVER_BINDING_PROTOCOL*This,
   IN EFI_HANDLE Controller,
   IN UINTN  NumberOfChildren,
   IN EFI_HANDLE *ChildHandleBuffer
   )
 {
   EFI_STATUSStatus;
   EFI_IDE_CONTROLLER_INIT_PROTOCOL  *IdeInit;
   EFI_SATA_CONTROLLER_PRIVATE_DATA  *SataPrivateData;
 
   //
   // Open the produced protocol
   //
   Status = gBS->OpenProtocol (
   Controller,
   ,
   (VOID **) ,
   This->DriverBindingHandle,
   Controller,
   EFI_OPEN_PROTOCOL_GET_PROTOCOL
   );
   if (EFI_ERROR (Status)) {
 return EFI_UNSUPPORTED;
   }
 
   SataPrivateData = SATA_CONTROLLER_PRIVATE_DATA_FROM_THIS (IdeInit);
   ASSERT (SataPrivateData != NULL);
 
   //
   // Uninstall the IDE Controller Init Protocol from this instance
   //
   Status = gBS->UninstallMultipleProtocolInterfaces (
   Controller,
   ,
   &(SataPrivateData->IdeInit),
   NULL
   );
   if (EFI_ERROR (Status)) {
 return Status;
   }
 
-  if (SataPrivateData != NULL) {
-if (SataPrivateData->DisqualifiedModes != NULL) {
-  FreePool (SataPrivateData->DisqualifiedModes);
-}
-if (SataPrivateData->IdentifyData != NULL) {
-  FreePool (SataPrivateData->IdentifyData);
-}
-if (SataPrivateData->IdentifyValid != NULL) {
-  FreePool (SataPrivateData->IdentifyValid);
-}
-FreePool (SataPrivateData);
+  if (SataPrivateData->DisqualifiedModes != NULL) {
+FreePool (SataPrivateData->DisqualifiedModes);
   }
+  if (SataPrivateData->IdentifyData != NULL) {
+FreePool (SataPrivateData->IdentifyData);
+  }
+  if (SataPrivateData->IdentifyValid != NULL) {
+FreePool (SataPrivateData->IdentifyValid);
+  }
+  FreePool (SataPrivateData);
 
   //
   // Restore original PCI attributes
   //
   SataPrivateData->PciIo->Attributes (
 SataPrivateData->PciIo,
 EfiPciIoAttributeOperationSet,
 SataPrivateData->OriginalPciAttributes,
 NULL
 );
 
   //
   // Close protocols opened by Sata Controller driver
   //
   return gBS->CloseProtocol (
 Controller,
 ,
 This->DriverBindingHandle,
 Controller
 );
 }
 
 /**
   Calculate the flat array subscript of a (Channel, Device) pair.
 
   @param[in] SataPrivateData  The private data structure corresponding to the
   SATA controller that attaches the device for
   which the flat array subscript is being
   calculated.
 
   @param[in] Channel  The channel (ie. port) number on the SATA
   controller that the device is attached to.
 
   @param[in] Device   The device number on the channel.
 
   @return  The flat array subscript suitable for indexing DisqualifiedModes,
IdentifyData, and IdentifyValid.
 **/
-- 
1.8.3.1


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

Re: [edk2] [PATCH] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for image verification failures

[Laszlo Ersek]

On 04/26/16 09:02, Cinnamon Shia wrote:
> Add DEBUG messages in DxeImageerificationLib to help debug Secure Boot image 
> verification failures
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Cinnamon Shia 
> Reviewed-by: Samer EL-Haj-Mahmoud 
> ---
>  .../DxeImageVerificationLib.c  | 38 
> +-
>  1 file changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c 
> b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> index 4b4d3bf..4322aac 100644
> --- a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> +++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> @@ -13,6 +13,7 @@
>untrusted PE/COFF image and validate its data structure within this image 
> buffer before use.
>  
>  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
> +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  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
> @@ -71,6 +72,8 @@ HASH_TABLE mHash[] = {
>{ L"SHA512", 64, [32], 9, Sha512GetContextSize, Sha512Init, 
> Sha512Update, Sha512Final}
>  };
>  
> +EFI_STRING mHashTypeStr;
> +
>  /**
>SecureBoot Hook for processing image verification.
>  
> @@ -340,6 +343,7 @@ HashPeImage (
>  return FALSE;
>}
>  
> +  mHashTypeStr = mHash[HashAlg].Name;
>CtxSize   = mHash[HashAlg].GetContextSize();
>  
>HashCtx = AllocatePool (CtxSize);
> @@ -1782,6 +1786,7 @@ ImageVerificationInAuditMode (
>UINT32   OffSet;
>CHAR16   *FilePathStr;
>UINTNSignatureListSize;
> +  EFI_STATUS   VerifyStatus;
>  
>SignatureList = NULL;
>WinCertificate= NULL;
> @@ -1873,6 +1878,7 @@ ImageVerificationInAuditMode (
>  //
>  // The information can't be got from the invalid PeImage
>  //
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid. Cannot 
> retrieve image information.\n"));
>  goto END;
>}
>  
> @@ -1896,6 +1902,7 @@ ImageVerificationInAuditMode (
>  //
>  // It is not a valid Pe/Coff file.
>  //
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Not a valid PE/COFF 
> image.\n"));
>  Status = EFI_ACCESS_DENIED;
>  goto END;
>}
> @@ -1942,6 +1949,7 @@ ImageVerificationInAuditMode (
>  // and not be reflected in the security data base "dbx".
>  //
>  if (!HashPeImage (HASHALG_SHA256)) {
> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Failed to hash this 
> image using %s.\n", mHashTypeStr));
>Status = EFI_ACCESS_DENIED;
>goto END;
>  }
> @@ -1955,7 +1963,14 @@ ImageVerificationInAuditMode (
>//
>if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
> mImageDigest, , mImageDigestSize)) {
>  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
> EFI_IMAGE_EXECUTION_INITIALIZED;
> +  } else {
> +//
> +// Image Hash is not in DB/DBX
> +//
> +DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not signed 
> and %s hash of image is not found in DB/DBX.\n", mHashTypeStr));
>}
> +} else {
> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not signed and 
> %s hash of image is rejected by DBX.\n", mHashTypeStr));
>  }
>  
>  //
> @@ -2029,7 +2044,11 @@ ImageVerificationInAuditMode (
>  // Check the digital signature against the valid certificate in allowed 
> database (db).
>  //
>  if (!IsForbiddenByDbx (AuthData, AuthDataSize, TRUE, FilePathStr, File)) 
> {
> -  IsAllowedByDb (AuthData, AuthDataSize, TRUE, FilePathStr, File);
> +  if (IsAllowedByDb (AuthData, AuthDataSize, TRUE, FilePathStr, File)) {
> +VerifyStatus = EFI_SUCCESS;
> +  }

Is this a logic change / fix? If it is, then it should go into a
separate patch.

Thanks
Laszlo

> +} else {
> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is signed but 
> signature is rejected by DBX.\n"));
>  }
>  
>  //
> @@ -2038,7 +2057,13 @@ ImageVerificationInAuditMode (
>  if (!IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE1, 
> mImageDigest, , mImageDigestSize)) {
>if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
> mImageDigest, , mImageDigestSize)) {
>  Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
> EFI_IMAGE_EXECUTION_INITIALIZED; 
> +  } else {
> +if (VerifyStatus != EFI_SUCCESS) {
> +  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is signed but 
> signature and %s hash of image are not found in DB/DBX.\n", mHashTypeStr));
> +}
>  

Re: [edk2] [PATCH] ShellPkg: Fix pci command for '_e' option

[Attar, Abdul Lateef]

Hi,
Could someone please commit this change, if have no objection.
Thanks
AbduL

From: Qiu, Shumin 
Sent: Friday, April 22, 2016 7:50:48 AM
To: Attar, Abdul Lateef; Carsey, Jaben; Ni, Ruiyu; edk2-devel@lists.01.org
Cc: Parthasarathy, Mohan (HPE Servers); Lakshminarasimha, Sunil Vishwanathpur
Subject: RE: [edk2] [PATCH] ShellPkg: Fix pci command for '_e' option

Reviewed-by: Qiu Shumin 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Abdul 
Lateef Attar
Sent: Thursday, April 21, 2016 7:24 PM
To: Carsey, Jaben; Ni, Ruiyu; Qiu, Shumin; edk2-devel@lists.01.org
Cc: mohan_parthasara...@hpe.com; sunil...@hpe.com
Subject: [edk2] [PATCH] ShellPkg: Fix pci command for '_e' option

ShellPkg: Fix pci command for '_e' option

Processing of '_e' argument was missing.
Added fix, to process the '_e' option
for printing additional AER information.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Abdul Lateef Attar 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c
index 4a8a97b..337495e 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c
@@ -2370,6 +2370,7 @@ PCI_CONFIG_SPACE  *mConfigSpace = NULL;  STATIC CONST 
SHELL_PARAM_ITEM ParamList[] = {
   {L"-s", TypeValue},
   {L"-i", TypeFlag},
+  {L"-_e", TypeFlag},
   {NULL, TypeMax}
   };

--
1.9.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] [Patch] NetworkPkg: Avoid the indefinite wait case in HttpDxe

[Jiaxin Wu]

Need the timer check to avoid the indefinite wait case
in HttpDxe driver
A.HTTP receive Header process in HttpTcpReceiveHeader();
B.HTTP receive Body process in HttpTcpReceiveBody();

Cc: Hegde Nagaraj P 
Cc: El-Haj-Mahmoud Samer 
Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Zhang Lubo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/HttpDxe/HttpImpl.c  | 60 --
 NetworkPkg/HttpDxe/HttpProto.c | 59 ++---
 NetworkPkg/HttpDxe/HttpProto.h | 15 +++
 3 files changed, 117 insertions(+), 17 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index 63b683e..fe2acbc 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -174,10 +174,11 @@ EfiHttpConfigure (
 >IPv4Node,
 HttpConfigData->AccessPoint.IPv4Node,
 sizeof (HttpInstance->IPv4Node)
 );
 }
+
 //
 // Creat Tcp child
 //
 Status = HttpInitProtocol (HttpInstance, HttpInstance->LocalAddressIsIPv6);
 if (EFI_ERROR (Status)) {
@@ -894,11 +895,39 @@ HttpResponseWorker (
 }   
 
 HttpInstance->EndofHeader = 
 HttpInstance->HttpHeaders = 
 
-Status = HttpTcpReceiveHeader (HttpInstance, , );
+
+if (HttpInstance->TimeoutEvent == NULL) {
+  //
+  // Create TimeoutEvent for response
+  //
+  Status = gBS->CreateEvent (
+  EVT_TIMER,
+  TPL_CALLBACK,
+  NULL,
+  NULL,
+  >TimeoutEvent
+  );
+  if (EFI_ERROR (Status)) {
+goto Error;
+  }
+}
+
+//
+// Start the timer, and wait Timeout seconds to receive the header packet.
+//
+Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative, 
HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
+if (EFI_ERROR (Status)) {
+  goto Error;
+}
+
+Status = HttpTcpReceiveHeader (HttpInstance, , , 
HttpInstance->TimeoutEvent);
+
+gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
+
 if (EFI_ERROR (Status)) {
   goto Error;
 }
 
 ASSERT (HttpHeaders != NULL);
@@ -1095,14 +1124,41 @@ HttpResponseWorker (
 }
   }
 
   ASSERT (HttpInstance->MsgParser != NULL);
 
+  if (HttpInstance->TimeoutEvent == NULL) {
+//
+// Create TimeoutEvent for response
+//
+Status = gBS->CreateEvent (
+EVT_TIMER,
+TPL_CALLBACK,
+NULL,
+NULL,
+>TimeoutEvent
+);
+if (EFI_ERROR (Status)) {
+  goto Error;
+}
+  }
+
+  //
+  // Start the timer, and wait Timeout seconds to receive the body packet.
+  //
+  Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative, 
HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
+  if (EFI_ERROR (Status)) {
+goto Error;
+  }
+
   //
   // We still need receive more data when there is no cache data and MsgParser 
is not NULL;
   //
-  Status = HttpTcpReceiveBody (Wrap, HttpMsg);
+  Status = HttpTcpReceiveBody (Wrap, HttpMsg, HttpInstance->TimeoutEvent);
+
+  gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
+
   if (EFI_ERROR (Status)) {
 goto Error;
   }
 
   return Status;
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c
index 156f138..eb2af7f 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -813,10 +813,15 @@ HttpCleanProtocol (
 {
   HttpCloseConnection (HttpInstance);
   
   HttpCloseTcpConnCloseEvent (HttpInstance);
 
+  if (HttpInstance->TimeoutEvent != NULL) {
+gBS->CloseEvent (HttpInstance->TimeoutEvent);
+HttpInstance->TimeoutEvent = NULL;
+  }
+
   if (HttpInstance->CacheBody != NULL) {
 FreePool (HttpInstance->CacheBody);
 HttpInstance->CacheBody = NULL;
 HttpInstance->NextMsg   = NULL;
   }
@@ -1537,20 +1542,22 @@ HttpTcpReceive (
   Receive the HTTP header by processing the associated HTTP token.
 
   @param[in]   HttpInstance The HTTP instance private data.
   @param[in, out]  SizeofHeadersThe HTTP header length.
   @param[in, out]  BufferSize   The size of buffer to cacahe the header 
message.
+  @param[in]   Timeout  The time to wait for receiving the header 
packet.
   
   @retval EFI_SUCCESS   The HTTP header is received.   
   
   @retval OthersOther errors as indicated.
 
 **/
 EFI_STATUS
 HttpTcpReceiveHeader (
   IN  HTTP_PROTOCOL *HttpInstance,
   IN  OUT UINTN *SizeofHeaders,
-  IN  OUT UINTN *BufferSize
+  IN  OUT UINTN *BufferSize,
+  IN  EFI_EVENT Timeout
   )
 {
   EFI_STATUSStatus;
   

Re: [edk2] A logic error in OvmfPkg\SataControllerDxe\SataController.c

[Laszlo Ersek]

On 04/26/16 09:28, Ni, Ruiyu wrote:
> Adding Laszlo & Jordan,
> It sounds like a trivial bug.

Sigh. This is my mess, from commit bcab71413407e. Thanks for the report,
I'll fix it up soon. :(

Thanks
Laszlo

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of wang 
>> xiaofeng
>> Sent: Tuesday, April 26, 2016 3:02 PM
>> To: Ni, Ruiyu 
>> Cc: edk2-devel@lists.01.org
>> Subject: [edk2] A logic error in OvmfPkg\SataControllerDxe\SataController.c
>>
>> Hi All ,
>> I found a logic error in SataControllerStop of 
>> OvmfPkg\SataControllerDxe\SataController.c.
>>The following code will first free SataPrivateData ,then try to use 
>> SataPrivateData
>>
>>
>> if (SataPrivateData != NULL) {
>>if (SataPrivateData->DisqualifiedModes != NULL) {
>>  FreePool (SataPrivateData->DisqualifiedModes);
>>}
>>if (SataPrivateData->IdentifyData != NULL) {
>>  FreePool (SataPrivateData->IdentifyData);
>>}
>>if (SataPrivateData->IdentifyValid != NULL) {
>>  FreePool (SataPrivateData->IdentifyValid);
>>}
>>FreePool (SataPrivateData);
>>  }
>>
>>
>>  //
>>  // Restore original PCI attributes
>>  //
>>  SataPrivateData->PciIo->Attributes (
>>SataPrivateData->PciIo,
>>EfiPciIoAttributeOperationSet,
>>SataPrivateData->OriginalPciAttributes,
>>NULL
>>);
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [PATCH] SecuritPkg: DxeImageVerificationLib: Fix wrong verification logic in DBX & DBT

[Laszlo Ersek]

On 04/26/16 05:49, Zhang, Chao B wrote:
> Hi all:
> It looks like final decision on security fix procedure has not been
> made clear. Should I check-in the patch under review or block and
> wait for the final decision?

Sorry about the delay.

If you have received positive review feedback from the package
(co-)maintainer(s), then please go ahead and commit+push the patch.

(

The discussion about embargos and responsible disclosure does not affect
the part of the workflow that is between posting a patch to a public
mailing list and pushing the patch to a public repo.

Instead, the discussion is about the part of the workflow where the
knowledge of the security issue transitions from private to public. That
is, *before* the patch is posted to the public mailing list. Once the
patch is posted publicly, the cat is out of the bag.

)

Thanks
Laszlo

> Thanks & Best regards
> Chao Zhang
> 
> 
> -Original Message-
> From: Mangefeste, Tony 
> Sent: Saturday, April 16, 2016 12:02 AM
> To: Peter Jones; Dick Wilkins
> Cc: edk2-de...@ml01.01.org; Kevin Davis; Laszlo Ersek; Zhang, Chao B; Long, 
> Qin
> Subject: RE: [edk2] [PATCH] SecuritPkg: DxeImageVerificationLib: Fix wrong 
> verification logic in DBX & DBT
> 
> Yes, this process needs refinement, it's on my list of things to worry about.
> 
> We will have a standard way for handling security issues, and part of the 
> upcoming rollout of our defect management system, procedure will target 
> security bugs.
> 
> Got the memo, it's a problem we'll work on a fix.  
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Peter Jones
>> Sent: Friday, April 15, 2016 8:44 AM
>> To: Dick Wilkins 
>> Cc: edk2-de...@ml01.01.org; Kevin Davis ; 
>> Laszlo Ersek ; Zhang, Chao B 
>> ; Long, Qin 
>> Subject: Re: [edk2] [PATCH] SecuritPkg: DxeImageVerificationLib: Fix 
>> wrong verification logic in DBX & DBT
>>
>> On Fri, Apr 15, 2016 at 08:10:50AM -0700, Dick Wilkins wrote:
>>> Peter,
>>>
>>> Yes, we definatly have a broken procedure here. I think that Tony M.
>> needs to work with the USRT to develop a procedure for handling 
>> security issues in the open-source code. The general flow should be:
>>>
>>> 1- A security vulnerability is found and is reported to the USRT as 
>>> well as
>> the Tianocore security alias.
>>> 2- The USRT opens a tracking ticket and evaluates the severity and 
>>> decides
>> on how to proceed.
>>> 3- In most cases, we report the problem to our "notify" email alias,
>> preferably with the fix, and IBVs and OEMs adopt the fix.
>>> 4- After a suitable timeframe, the problem and fix are disclosed by 
>>> checking
>> in the code change to the open-source repository.
>>> 5- If appropriate, after the fix is widely available and adopted, a 
>>> CVE is
>> created.
>>
>> CVE should be step 3 here, not step 5.  You don't actually have to 
>> disclose what's broken or what the fix is to get a CVE allocated - 
>> often we get them as soon as we know there's a problem, sometimes 
>> without even knowing if it's possible to write an exploit.  It's best 
>> to do it before the notification step if possible - that way the fix's 
>> commit message (and the USRT ticket) can say what CVE it's for, and 
>> when any level of public disclosure happens later, it'll include that.  
>> That in turn also means firmware updates' change logs can include the same 
>> CVE number.
>> Even if it's in something that doesn't get publicly disclosed (say a 
>> BSP driver or other hardware support package), the same is true.  That 
>> way it's easy for IBVs and OEMs to match up the private thing with the 
>> publicly disclosed info, and for consumers to figure out if they got the fix 
>> for a given vulnerability.
>>
>>> This is my proposal as chair of the UEFI Security Response team. For 
>>> those not familiar with us, please visit http://uefi.org/security.
>>> Please feel free to provide input on this proposed process.
>>
>>>
>>> Thanks,
>>> Dick Wilkins
>>>
>>> 
>>> From: edk2-devel [edk2-devel-boun...@lists.01.org] On Behalf Of 
>>> Peter Jones [pjo...@redhat.com]
>>> Sent: Friday, April 15, 2016 10:51 AM
>>> To: Zhang, Chao B
>>> Cc: edk2-de...@ml01.01.org; Kevin Davis; Laszlo Ersek; Long, Qin
>>> Subject: Re: [edk2] [PATCH] SecuritPkg: DxeImageVerificationLib: Fix 
>>> wrong verification logic in DBX & DBT
>>>
>>> On Fri, Apr 15, 2016 at 12:40:14AM +, Zhang, Chao B wrote:
 Hi all:
   Thank you very much for the info. Do you agree to add "[USRT
   0001604]: Bug found in SecuritPkg: DxeImageVerificationLib" into the
   log & check in this patch?
>>>
>>> What's the point of adding our internal tracker to it?  If anything 
>>> the CVE should be part of the commit message.  So we should still do 
>>> that, and tracking the progress in doing so with a 

Re: [edk2] [Xen-devel] OVMF broken under Xen (in PCI initialisation)

[Gary Lin]

On Tue, Apr 26, 2016 at 10:31:22AM +0100, Andrew Cooper wrote:
> 
> > I tried to make RootBridgeIoConfiguration() return EFI_UNSUPPORTED
> > (see the attachment), and those asserts were gone. However, the system
> > stuck somewhere after loading shell.efi. Here are the messages from the
> > debug log:
> >
> > BdsLibConnectAll
> > Select Item: 0xE
> > Memory  Previous  CurrentNext
> >  TypePages Pages Pages
> > ==      
> >   0A0004  0001  0004
> >   090008  0011  0015
> >   000004  0001  0004
> >   060024  0057  006C
> >   050030  0063  007B
> >   030180  048D  05B0
> >   040F00  0B65  0F00
> > Booting EFI Internal Shell
> > InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 3EA580C0
> > Loading driver at 0x0003E03F000 EntryPoint=0x0003E03F240 Shell.efi
> > InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 3EA58B98
> > InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B 3EA54320
> > InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA 3EA53CD8
> > InstallProtocolInterface: 6302D008-7F9B-4F30-87AC-60C9FEF5DA4E 3E16B580
> >
> > I couldn't find out where it stuck unless there is a way to attach gdb
> > to Xen HVM for source level debugging :-(
> 
> You can use gdbsx (from tools/debugger/gdbsx in the Xen tree) which acts
> like gdbserver.  (It is very rough around the edges, but does function.)
> 
Thanks for the hint!
Now I got the backtrace:

Program received signal SIGINT, Interrupt.
0x3f539cd2 in CpuSleep ()
(gdb) bt
#0  0x3f539cd2 in CpuSleep ()
#1  0x3f5359fc in IdleLoopEventCallback (Event=0x3eea8dd8, Context=0x0) 
at /home/linux/git/edk2/UefiCpuPkg/CpuDxe/CpuDxe.c:852
#2  0x3f66a9b2 in CoreDispatchEventNotifies (Priority=16) at 
/home/linux/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:200
#3  0x3f66a007 in CoreRestoreTpl (NewTpl=4) at 
/home/linux/git/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c:131
#4  0x3f6581c3 in CoreReleaseLock (Lock=0x3f688d70) at 
/home/linux/git/edk2/MdeModulePkg/Core/Dxe/Library/Library.c:102
#5  0x3f66a78d in CoreReleaseEventLock () at 
/home/linux/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:119
#6  0x3f66abf9 in CoreNotifySignalList (EventGroup=0x3f404ad0) at 
/home/linux/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:276
#7  0x3f66b08d in CoreSignalEvent (UserEvent=0x3f404a98) at 
/home/linux/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:564
#8  0x3f66b2c4 in CoreWaitForEvent (NumberOfEvents=1, 
UserEvents=0x3e3e2060, UserIndex=0x3f64c848)
at /home/linux/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:705
#9  0x3e052317 in FileInterfaceStdInRead (This=0x3e16b700, 
BufferSize=0x3f64ca00, Buffer=0x3e8d3018)
at /home/linux/git/edk2/ShellPkg/Application/Shell/FileHandleWrappers.c:422
#10 0x3e062372 in FileHandleRead (FileHandle=0x3e16b700, 
BufferSize=0x3f64ca00, Buffer=0x3e8d3018)
at 
/home/linux/git/edk2/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c:179
#11 0x3e04374e in DoShellPrompt () at 
/home/linux/git/edk2/ShellPkg/Application/Shell/Shell.c:1278
#12 0x3e041d0e in UefiMain (ImageHandle=0x3ea58b18, 
SystemTable=0x3f5d9018) at 
/home/linux/git/edk2/ShellPkg/Application/Shell/Shell.c:634
#13 0x3e040492 in ProcessModuleEntryPointList (ImageHandle=0x3ea58b18, 
SystemTable=0x3f5d9018)
at 
/home/linux/git/edk2/Build/OvmfX64/DEBUG_GCC48/X64/ShellPkg/Application/Shell/Shell/DEBUG/AutoGen.c:834
#14 0x3e03f2b1 in _ModuleEntryPoint (ImageHandle=0x3ea58b18, 
SystemTable=0x3f5d9018)
at 
/home/linux/git/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:65
#15 0x3f653791 in CoreStartImage (ImageHandle=0x3ea58b18, 
ExitDataSize=0x3f64cd38, ExitData=0x3f64cd30)
at /home/linux/git/edk2/MdeModulePkg/Core/Dxe/Image/Image.c:1661
#16 0x3f442fbc in BdsLibBootViaBootOption (Option=0x3ea63718, 
DevicePath=0x3ea58018, ExitDataSize=0x3f64cd38, ExitData=0x3f64cd30)
at 
/home/linux/git/edk2/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c:2436
#17 0x3f4130a3 in BdsBootDeviceSelect () at 
/home/linux/git/edk2/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:286
#18 0x3f413c1a in BdsEntry (This=0x3f45fe00) at 
/home/linux/git/edk2/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:659
#19 0x3f64e96a in DxeMain (HobStart=0x3f402018) at 
/home/linux/git/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:518
#20 0x3f64d71d in ProcessModuleEntryPointList (HobStart=0x3b6ce000)
at 
/home/linux/git/edk2/Build/OvmfX64/DEBUG_GCC48/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/AutoGen.c:414
#21 0x3f64d26d in _ModuleEntryPoint (HobStart=0x3b6ce000) at 
/home/linux/git/edk2/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:54
#22 0x in ?? ()
(gdb)

The shell was waiting 

Re: [edk2] OVMF broken under Xen (in PCI initialisation)

[Ni, Ruiyu]

Gary,
I can reproduce the issue and have debugged to get the reason.
In MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c:
PciEnumeratorLight() calls PciRootBridgeIo->Configuration()
while the Configuration returns EFI_UNSUPPORTED resulting
the PciBus driver exits earlier.
You could try to manually set MinBus to 0 and MaxBus to 0xFF.

The second change you need to make is in PciIo.c:
Change GetMmioAddressTranslationOffset() to return 0 instead
of -1 when error occurs

With the above 2 changes, can you check whether the system can
boot?

If it can boot, then we need to think about what the proper fix is.
For OVMF above Xen, the PCI resources are assigned by Xen other than
PciBus driver. So PciRootBridgeIo->Configuration() doesn't know
the resource assignment information.
With old PciHostBridge driver, the Configuration() returns BUS resource
descriptor with MinBus = MaxBus = 0 (default value), so that the PciBus
driver can detect all devices in BUS 0, but I guess devices in BUS 1+ cannot
be detected.

Does Xen pass the resource assignment information through some memory
blob to firmware? If yes, we could think about let PciHostBridgeLib pass that
information to PciHostBridge driver. If no, we also could let PciHostBridgeLib
collect the information (IO/MEM/BUS resource assignment) and pass that
to PciHostBridgeDxe driver.

And we need to have a way to tell PciHostBridgeDxe the resource information
passed from PciHostBridgeLib is available resource to assign, or already 
allocated.
Maybe just depends on the PcdPciBusDisableEnumeration. still thinking.


Regards,
Ray

>-Original Message-
>From: Gary Lin [mailto:g...@suse.com]
>Sent: Tuesday, April 26, 2016 4:40 PM
>To: Ni, Ruiyu 
>Cc: edk2-devel@lists.01.org; Xen Devel 
>Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>
>On Tue, Apr 26, 2016 at 08:19:49AM +, Ni, Ruiyu wrote:
>> Gary,
>> Maybe the system boots to Shell well but the video isn't initialized 
>> properly.
>> Can you build the firmware using "-D DEBUG_ON_SERIAL_PORT" switch and
>> give me the boot log?
>>
>Hi Ray,
>
>I already did and it's how I make the firmware spit the log :-(
>
>Thanks,
>
>Gary Lin
>
>> Regards,
>> Ray
>>
>> From: Gary Lin [mailto:g...@suse.com]
>> Sent: Tuesday, April 26, 2016 3:35 PM
>> To: Ni, Ruiyu 
>> Cc: Anthony PERARD ; edk2-devel@lists.01.org; Xen 
>> Devel 
>> Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>>
>> On Tue, Apr 26, 2016 at 06:43:56AM +, Ni, Ruiyu wrote:
>> >
>> >
>> > Regards,
>> > Ray
>> >
>> > >-Original Message-
>> > >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> > >Anthony PERARD
>> > >Sent: Friday, April 22, 2016 10:48 PM
>> > >To: edk2-devel@lists.01.org
>> > >Cc: Xen Devel >
>> > >Subject: [edk2] OVMF broken under Xen (in PCI initialisation)
>> > >
>> > >Hi,
>> > >
>> > >Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci 
>> > >root
>> > >bridge does not finish to initialize and breaks under Xen.
>> > >
>> > >There are several issue probably due to the use of
>> > >PcdPciDisableBusEnumeration=TRUE.
>> > >
>> > >First one:
>> > >ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): 
>> > >Bridge->Mem.Limit <
>0x0001ULL
>> > >
>> > >This patch would fix the first assert:
>> > >diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
>> > >index 7fa9019..15ec7a7 100644
>> > >--- a/OvmfPkg/PlatformPei/Xen.c
>> > >+++ b/OvmfPkg/PlatformPei/Xen.c
>> > >@@ -227,5 +227,11 @@ InitializeXen (
>> > >
>> > >   PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
>> > >
>> > >+  // Values from hvmloader
>> > >+#define PCI_MEM_END 0xFC00
>> > >+#define HVM_BELOW_4G_MMIO_START 0xF000
>> > >+  PcdSet64 (PcdPciMmio32Base, HVM_BELOW_4G_MMIO_START);
>> > >+  PcdSet64 (PcdPciMmio32Size, PCI_MEM_END - HVM_BELOW_4G_MMIO_START);
>> > >+
>> > >   return EFI_SUCCESS;
>> > > }
>> > >
>> > >
>> > >But that not enough, next assert is:
>> > >ASSERT MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c(807): RootBridge 
>> > >!= ((void *) 0)
>> > >
>> > >I have worked around this one with the following patch. That would
>> > >correspond to how the former implementation in OvmfPkg was initializing 
>> > >the
>> > >struct. Maybe a better way would be to fill ResAllocated under Xen,
>> > >somehow. Under Xen, the ResAllocNode status is not allocated, so no
>> > >Descriptor are created.
>> > >
>> > >diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> > >b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> > >index cda9b49..eda92b6 100644
>> > >--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> > >+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> > >@@ -1509,15 +1509,13 @@ 

Re: [edk2] [PATCH v2] NetworkPkg: Allow user to create a HTTP corporate boot option in setup page.

[Wu, Jiaxin]

Reviewed-by: Jiaxin Wu 


> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, April 26, 2016 11:47 AM
> To: edk2-devel@lists.01.org
> Cc: Li Gary ; Ye, Ting ; Wu, Jiaxin
> 
> Subject: [PATCH v2] NetworkPkg: Allow user to create a HTTP corporate boot
> option in setup page.
> 
> This patch updates the HTTP Boot Configuration page to allow the user to
> create a corporate mode HTTP boot option, by leaving the URI string empty.
> The patch also fix a bug that the L"https://; should use StrnCmp() with
> Length 8.
> 
> Cc: Li Gary 
> Cc: Ye Ting 
> Cc: Wu Jiaxin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Fu Siyuan 
> ---
>  NetworkPkg/HttpBootDxe/HttpBootConfig.c| 9 +
>  NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h | 2 +-
>  2 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> index c47dddc..00e4782 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> @@ -79,9 +79,9 @@ HttpBootAddBootOption (
>}
> 
>//
> -  // Only accept http and https URI.
> +  // Only accept empty URI, or http and https URI.
>//
> -  if ((StrnCmp (Uri, L"http://;, 7) != 0) && (StrnCmp (Uri, L"https://;, 7) 
> != 0))
> {
> +  if ((StrLen (Uri) != 0) && (StrnCmp (Uri, L"http://;, 7) != 0) &&
> + (StrnCmp (Uri, L"https://;, 8) != 0)) {
>  return EFI_INVALID_PARAMETER;
>}
> 
> @@ -577,9 +577,10 @@ HttpBootFormCallback (
>  HiiSetString (CallbackInfo->RegisteredHandle, Value->string, Uri, NULL);
> 
>  //
> -// We only accept http and https, pop up a message box for unsupported
> URI.
> +// The URI should be either an empty string (for corporate
> environment) ,or http(s) for home environment.
> +// Pop up a message box for other unsupported URI.
>  //
> -if ((StrnCmp (Uri, L"http://;, 7) != 0) && (StrnCmp (Uri, L"https://;, 
> 7) != 0))
> {
> +if ((StrLen (Uri) != 0) && (StrnCmp (Uri, L"http://;, 7) != 0) &&
> + (StrnCmp (Uri, L"https://;, 8) != 0)) {
>CreatePopUp (
>  EFI_LIGHTGRAY | EFI_BACKGROUND_BLUE,
>  ,
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
> b/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
> index 37ce440..682306e 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
> +++ b/NetworkPkg/HttpBootDxe/HttpBootConfigNVDataStruc.h
> @@ -23,7 +23,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  //
>  // Macros used for an IPv4 or an IPv6 address.
>  //
> -#define URI_STR_MIN_SIZE 8
> +#define URI_STR_MIN_SIZE 0
>  #define URI_STR_MAX_SIZE 255
> 
>  #define DESCRIPTION_STR_MIN_SIZE 6
> --
> 2.7.4.windows.1

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

Re: [edk2] OVMF broken under Xen (in PCI initialisation)

[Gary Lin]

On Tue, Apr 26, 2016 at 08:19:49AM +, Ni, Ruiyu wrote:
> Gary,
> Maybe the system boots to Shell well but the video isn't initialized properly.
> Can you build the firmware using "-D DEBUG_ON_SERIAL_PORT" switch and
> give me the boot log?
> 
Hi Ray,

I already did and it's how I make the firmware spit the log :-(

Thanks,

Gary Lin

> Regards,
> Ray
> 
> From: Gary Lin [mailto:g...@suse.com]
> Sent: Tuesday, April 26, 2016 3:35 PM
> To: Ni, Ruiyu 
> Cc: Anthony PERARD ; edk2-devel@lists.01.org; Xen 
> Devel 
> Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
> 
> On Tue, Apr 26, 2016 at 06:43:56AM +, Ni, Ruiyu wrote:
> >
> >
> > Regards,
> > Ray
> >
> > >-Original Message-
> > >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > >Anthony PERARD
> > >Sent: Friday, April 22, 2016 10:48 PM
> > >To: edk2-devel@lists.01.org
> > >Cc: Xen Devel >
> > >Subject: [edk2] OVMF broken under Xen (in PCI initialisation)
> > >
> > >Hi,
> > >
> > >Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root
> > >bridge does not finish to initialize and breaks under Xen.
> > >
> > >There are several issue probably due to the use of
> > >PcdPciDisableBusEnumeration=TRUE.
> > >
> > >First one:
> > >ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): 
> > >Bridge->Mem.Limit < 0x0001ULL
> > >
> > >This patch would fix the first assert:
> > >diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
> > >index 7fa9019..15ec7a7 100644
> > >--- a/OvmfPkg/PlatformPei/Xen.c
> > >+++ b/OvmfPkg/PlatformPei/Xen.c
> > >@@ -227,5 +227,11 @@ InitializeXen (
> > >
> > >   PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
> > >
> > >+  // Values from hvmloader
> > >+#define PCI_MEM_END 0xFC00
> > >+#define HVM_BELOW_4G_MMIO_START 0xF000
> > >+  PcdSet64 (PcdPciMmio32Base, HVM_BELOW_4G_MMIO_START);
> > >+  PcdSet64 (PcdPciMmio32Size, PCI_MEM_END - HVM_BELOW_4G_MMIO_START);
> > >+
> > >   return EFI_SUCCESS;
> > > }
> > >
> > >
> > >But that not enough, next assert is:
> > >ASSERT MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c(807): RootBridge 
> > >!= ((void *) 0)
> > >
> > >I have worked around this one with the following patch. That would
> > >correspond to how the former implementation in OvmfPkg was initializing the
> > >struct. Maybe a better way would be to fill ResAllocated under Xen,
> > >somehow. Under Xen, the ResAllocNode status is not allocated, so no
> > >Descriptor are created.
> > >
> > >diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> > >b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> > >index cda9b49..eda92b6 100644
> > >--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> > >+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> > >@@ -1509,15 +1509,13 @@ RootBridgeIoConfiguration (
> > >
> > > ResAllocNode = >ResAllocNode[Index];
> > >
> > >-if (ResAllocNode->Status != ResAllocated) {
> > >-  continue;
> > >-}
> > >-
> > > Descriptor->Desc = ACPI_ADDRESS_SPACE_DESCRIPTOR;
> > > Descriptor->Len  = sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) - 3;
> > >+if (ResAllocNode->Status != ResAllocated) {
> > > Descriptor->AddrRangeMin  = ResAllocNode->Base;
> > > Descriptor->AddrRangeMax  = ResAllocNode->Base + ResAllocNode->Length 
> > > - 1;
> > > Descriptor->AddrLen   = ResAllocNode->Length;
> > >+}
> > > switch (ResAllocNode->Type) {
> > >
> > I think a more proper fix is to return EFI_UNSUPPORTED without returning any
> > descriptors when the PcdPciDisableBusEnumeration is TRUE.
> > Per UEFI Spec, EFI_UNSUPPORTED means "The current configuration of this PCI
> > root bridge could not be retrieved." It's true when the PCD is true.
> >
> > >
> > >That leads to one last assert:
> > >> QemuVideo: Cirrus 5446 detected
> > >> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 7B9EF598
> > >> Adding Mode 0 as Cirrus Internal Mode 0: 640x480, 32-bit, 60 Hz
> > >> Adding Mode 1 as Cirrus Internal Mode 1: 800x600, 32-bit, 60 Hz
> > >> Adding Mode 2 as Cirrus Internal Mode 2: 1024x768, 24-bit, 60 Hz
> > >> PixelBlueGreenRedReserved8BitPerColor
> > >> ASSERT 
> > >> /local/home/sheep/work/ovmf/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c(1789):
> > >>  ((BOOLEAN)(0==1))
> > >For this one, I've workaround by reverting patch 7b0a1ea
> > >(MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAttributes).
> > >That issue was introduce while still using the USE_OLD_PCI_HOST.
> > >
> > >Any idee or pointer on how to fix those issues ?
> >
> > When the PciRootBridgeIo.Configuration() returns EFI_UNSUPPORTED, this 
> > assertion
> > can be fixed as well. Correct?
> 
> I tried to make RootBridgeIoConfiguration() return EFI_UNSUPPORTED
> (see the 

Re: [edk2] [PATCH] MdeModulePkg DxeCore: Check free memory type by CoreUpdateProfile()

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com


> -Original Message-
> From: Zeng, Star
> Sent: Friday, April 22, 2016 2:37 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Tian, Feng 
> Subject: [PATCH] MdeModulePkg DxeCore: Check free memory type by
> CoreUpdateProfile()
> 
> It can improve profile performance, especially when
> PcdMemoryProfileMemoryType configured without EfiBootServicesData.
> CoreUpdateProfile() can return quickly, but not depend on the further
> code to find the buffer not recorded and then return.
> 
> Cc: Jiewen Yao 
> Cc: Feng Tian 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Core/Dxe/DxeMain.h |  2 +-
>  MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c | 13 -
>  MdeModulePkg/Core/Dxe/Mem/Page.c|  2 +-
>  MdeModulePkg/Core/Dxe/Mem/Pool.c|  2 +-
>  4 files changed, 7 insertions(+), 12 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h
> b/MdeModulePkg/Core/Dxe/DxeMain.h
> index 82a3a9b4f2b7..e6b9114d2ee5 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain.h
> +++ b/MdeModulePkg/Core/Dxe/DxeMain.h
> @@ -2821,7 +2821,7 @@ BOOLEAN
>  CoreUpdateProfile (
>IN EFI_PHYSICAL_ADDRESS   CallerAddress,
>IN MEMORY_PROFILE_ACTION  Action,
> -  IN EFI_MEMORY_TYPEMemoryType, // Valid for
> AllocatePages/AllocatePool
> +  IN EFI_MEMORY_TYPEMemoryType,
>IN UINTN  Size,   // Valid for
> AllocatePages/FreePages/AllocatePool
>IN VOID   *Buffer
>);
> diff --git a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
> b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
> index 158803746126..6626e101592e 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
> @@ -1105,7 +1105,7 @@ BOOLEAN
>  CoreUpdateProfile (
>IN PHYSICAL_ADDRESS   CallerAddress,
>IN MEMORY_PROFILE_ACTION  Action,
> -  IN EFI_MEMORY_TYPEMemoryType, // Valid for
> AllocatePages/AllocatePool
> +  IN EFI_MEMORY_TYPEMemoryType,
>IN UINTN  Size,   // Valid for
> AllocatePages/FreePages/AllocatePool
>IN VOID   *Buffer
>)
> @@ -1121,15 +1121,10 @@ CoreUpdateProfile (
>}
> 
>//
> -  // Free operations have no memory type information, so skip the check.
> +  // Only record limited MemoryType.
>//
> -  if ((Action == MemoryProfileActionAllocatePages) || (Action ==
> MemoryProfileActionAllocatePool)) {
> -//
> -// Only record limited MemoryType.
> -//
> -if (!CoreNeedRecordProfile (MemoryType)) {
> -  return FALSE;
> -}
> +  if (!CoreNeedRecordProfile (MemoryType)) {
> +return FALSE;
>}
> 
>ContextData = GetMemoryProfileContext ();
> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> index dbdc71b59ca5..898b722a4319 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> @@ -1444,7 +1444,7 @@ CoreFreePages (
> 
>Status = CoreInternalFreePages (Memory, NumberOfPages,
> );
>if (!EFI_ERROR (Status)) {
> -CoreUpdateProfile ((EFI_PHYSICAL_ADDRESS) (UINTN)
> RETURN_ADDRESS (0), MemoryProfileActionFreePages,
> (EFI_MEMORY_TYPE) 0, EFI_PAGES_TO_SIZE (NumberOfPages), (VOID *)
> (UINTN) Memory);
> +CoreUpdateProfile ((EFI_PHYSICAL_ADDRESS) (UINTN)
> RETURN_ADDRESS (0), MemoryProfileActionFreePages, MemoryType,
> EFI_PAGES_TO_SIZE (NumberOfPages), (VOID *) (UINTN) Memory);
>  InstallMemoryAttributesTableOnMemoryAllocation (MemoryType);
>}
>return Status;
> diff --git a/MdeModulePkg/Core/Dxe/Mem/Pool.c
> b/MdeModulePkg/Core/Dxe/Mem/Pool.c
> index 5eced88efb75..fec20a9e6eee 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/Pool.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/Pool.c
> @@ -505,7 +505,7 @@ CoreFreePool (
> 
>Status = CoreInternalFreePool (Buffer, );
>if (!EFI_ERROR (Status)) {
> -CoreUpdateProfile ((EFI_PHYSICAL_ADDRESS) (UINTN)
> RETURN_ADDRESS (0), MemoryProfileActionFreePool, (EFI_MEMORY_TYPE)
> 0, 0, Buffer);
> +CoreUpdateProfile ((EFI_PHYSICAL_ADDRESS) (UINTN)
> RETURN_ADDRESS (0), MemoryProfileActionFreePool, PoolType, 0, Buffer);
>  InstallMemoryAttributesTableOnMemoryAllocation (PoolType);
>}
>return Status;
> --
> 2.7.0.windows.1

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

Re: [edk2] [patch] MdeModulePkg: BOOLEAN type needn't to compare to TRUE/FALSE explicitly

[Qiu, Shumin]

Reviewed-by: Qiu Shumin 

-Original Message-
From: Bi, Dandan 
Sent: Tuesday, April 26, 2016 4:25 PM
To: edk2-devel@lists.01.org
Cc: Qiu, Shumin; Dong, Eric
Subject: [patch] MdeModulePkg: BOOLEAN type needn't to compare to TRUE/FALSE 
explicitly

Fix this issue to follow the coding style.

Cc: Qiu Shumin 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c 
b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
index 24b6b24..cc155cc 100644
--- a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
+++ b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
@@ -937,11 +937,11 @@ CompareAndMergeDefaultString (
   }
 
   //
   // If the ConfigAltResp has no change,no need to update the content in 
AltCfgResp.
   //
-  if (ConfigAltRespChanged == FALSE) {
+  if (!ConfigAltRespChanged) {
 Status = EFI_SUCCESS;
 goto Exit;
   }
   //
   // ConfigAltResp has been changed, need to update the content in AltCfgResp.
-- 
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: BOOLEAN type needn't to compare to TRUE/FALSE explicitly

[Dandan Bi]

Fix this issue to follow the coding style.

Cc: Qiu Shumin 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c 
b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
index 24b6b24..cc155cc 100644
--- a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
+++ b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
@@ -937,11 +937,11 @@ CompareAndMergeDefaultString (
   }
 
   //
   // If the ConfigAltResp has no change,no need to update the content in 
AltCfgResp.
   //
-  if (ConfigAltRespChanged == FALSE) {
+  if (!ConfigAltRespChanged) {
 Status = EFI_SUCCESS;
 goto Exit;
   }
   //
   // ConfigAltResp has been changed, need to update the content in AltCfgResp.
-- 
1.9.5.msysgit.1

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

Re: [edk2] OVMF broken under Xen (in PCI initialisation)

[Ni, Ruiyu]

Gary,
Maybe the system boots to Shell well but the video isn't initialized properly.
Can you build the firmware using "-D DEBUG_ON_SERIAL_PORT" switch and
give me the boot log?

Regards,
Ray

From: Gary Lin [mailto:g...@suse.com]
Sent: Tuesday, April 26, 2016 3:35 PM
To: Ni, Ruiyu 
Cc: Anthony PERARD ; edk2-devel@lists.01.org; Xen 
Devel 
Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)

On Tue, Apr 26, 2016 at 06:43:56AM +, Ni, Ruiyu wrote:
>
>
> Regards,
> Ray
>
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> >Anthony PERARD
> >Sent: Friday, April 22, 2016 10:48 PM
> >To: edk2-devel@lists.01.org
> >Cc: Xen Devel >
> >Subject: [edk2] OVMF broken under Xen (in PCI initialisation)
> >
> >Hi,
> >
> >Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root
> >bridge does not finish to initialize and breaks under Xen.
> >
> >There are several issue probably due to the use of
> >PcdPciDisableBusEnumeration=TRUE.
> >
> >First one:
> >ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): 
> >Bridge->Mem.Limit < 0x0001ULL
> >
> >This patch would fix the first assert:
> >diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
> >index 7fa9019..15ec7a7 100644
> >--- a/OvmfPkg/PlatformPei/Xen.c
> >+++ b/OvmfPkg/PlatformPei/Xen.c
> >@@ -227,5 +227,11 @@ InitializeXen (
> >
> >   PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
> >
> >+  // Values from hvmloader
> >+#define PCI_MEM_END 0xFC00
> >+#define HVM_BELOW_4G_MMIO_START 0xF000
> >+  PcdSet64 (PcdPciMmio32Base, HVM_BELOW_4G_MMIO_START);
> >+  PcdSet64 (PcdPciMmio32Size, PCI_MEM_END - HVM_BELOW_4G_MMIO_START);
> >+
> >   return EFI_SUCCESS;
> > }
> >
> >
> >But that not enough, next assert is:
> >ASSERT MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c(807): RootBridge != 
> >((void *) 0)
> >
> >I have worked around this one with the following patch. That would
> >correspond to how the former implementation in OvmfPkg was initializing the
> >struct. Maybe a better way would be to fill ResAllocated under Xen,
> >somehow. Under Xen, the ResAllocNode status is not allocated, so no
> >Descriptor are created.
> >
> >diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> >b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> >index cda9b49..eda92b6 100644
> >--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> >+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> >@@ -1509,15 +1509,13 @@ RootBridgeIoConfiguration (
> >
> > ResAllocNode = >ResAllocNode[Index];
> >
> >-if (ResAllocNode->Status != ResAllocated) {
> >-  continue;
> >-}
> >-
> > Descriptor->Desc = ACPI_ADDRESS_SPACE_DESCRIPTOR;
> > Descriptor->Len  = sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) - 3;
> >+if (ResAllocNode->Status != ResAllocated) {
> > Descriptor->AddrRangeMin  = ResAllocNode->Base;
> > Descriptor->AddrRangeMax  = ResAllocNode->Base + ResAllocNode->Length - 
> > 1;
> > Descriptor->AddrLen   = ResAllocNode->Length;
> >+}
> > switch (ResAllocNode->Type) {
> >
> I think a more proper fix is to return EFI_UNSUPPORTED without returning any
> descriptors when the PcdPciDisableBusEnumeration is TRUE.
> Per UEFI Spec, EFI_UNSUPPORTED means "The current configuration of this PCI
> root bridge could not be retrieved." It's true when the PCD is true.
>
> >
> >That leads to one last assert:
> >> QemuVideo: Cirrus 5446 detected
> >> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 7B9EF598
> >> Adding Mode 0 as Cirrus Internal Mode 0: 640x480, 32-bit, 60 Hz
> >> Adding Mode 1 as Cirrus Internal Mode 1: 800x600, 32-bit, 60 Hz
> >> Adding Mode 2 as Cirrus Internal Mode 2: 1024x768, 24-bit, 60 Hz
> >> PixelBlueGreenRedReserved8BitPerColor
> >> ASSERT 
> >> /local/home/sheep/work/ovmf/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c(1789): 
> >> ((BOOLEAN)(0==1))
> >For this one, I've workaround by reverting patch 7b0a1ea
> >(MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAttributes).
> >That issue was introduce while still using the USE_OLD_PCI_HOST.
> >
> >Any idee or pointer on how to fix those issues ?
>
> When the PciRootBridgeIo.Configuration() returns EFI_UNSUPPORTED, this 
> assertion
> can be fixed as well. Correct?

I tried to make RootBridgeIoConfiguration() return EFI_UNSUPPORTED
(see the attachment), and those asserts were gone. However, the system
stuck somewhere after loading shell.efi. Here are the messages from the
debug log:

BdsLibConnectAll
Select Item: 0xE
Memory  Previous  CurrentNext
 TypePages Pages Pages
==      
  0A0004  0001  0004
  090008  0011  0015
  000004  0001  0004
  06  

Re: [edk2] OVMF broken under Xen (in PCI initialisation)

[Gary Lin]

On Tue, Apr 26, 2016 at 06:43:56AM +, Ni, Ruiyu wrote:
> 
> 
> Regards,
> Ray
> 
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> >Anthony PERARD
> >Sent: Friday, April 22, 2016 10:48 PM
> >To: edk2-devel@lists.01.org
> >Cc: Xen Devel 
> >Subject: [edk2] OVMF broken under Xen (in PCI initialisation)
> >
> >Hi,
> >
> >Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root
> >bridge does not finish to initialize and breaks under Xen.
> >
> >There are several issue probably due to the use of
> >PcdPciDisableBusEnumeration=TRUE.
> >
> >First one:
> >ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): 
> >Bridge->Mem.Limit < 0x0001ULL
> >
> >This patch would fix the first assert:
> >diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
> >index 7fa9019..15ec7a7 100644
> >--- a/OvmfPkg/PlatformPei/Xen.c
> >+++ b/OvmfPkg/PlatformPei/Xen.c
> >@@ -227,5 +227,11 @@ InitializeXen (
> >
> >   PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
> >
> >+  // Values from hvmloader
> >+#define PCI_MEM_END 0xFC00
> >+#define HVM_BELOW_4G_MMIO_START 0xF000
> >+  PcdSet64 (PcdPciMmio32Base, HVM_BELOW_4G_MMIO_START);
> >+  PcdSet64 (PcdPciMmio32Size, PCI_MEM_END - HVM_BELOW_4G_MMIO_START);
> >+
> >   return EFI_SUCCESS;
> > }
> >
> >
> >But that not enough, next assert is:
> >ASSERT MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c(807): RootBridge != 
> >((void *) 0)
> >
> >I have worked around this one with the following patch. That would
> >correspond to how the former implementation in OvmfPkg was initializing the
> >struct. Maybe a better way would be to fill ResAllocated under Xen,
> >somehow. Under Xen, the ResAllocNode status is not allocated, so no
> >Descriptor are created.
> >
> >diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> >b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> >index cda9b49..eda92b6 100644
> >--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> >+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> >@@ -1509,15 +1509,13 @@ RootBridgeIoConfiguration (
> >
> > ResAllocNode = >ResAllocNode[Index];
> >
> >-if (ResAllocNode->Status != ResAllocated) {
> >-  continue;
> >-}
> >-
> > Descriptor->Desc = ACPI_ADDRESS_SPACE_DESCRIPTOR;
> > Descriptor->Len  = sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) - 3;
> >+if (ResAllocNode->Status != ResAllocated) {
> > Descriptor->AddrRangeMin  = ResAllocNode->Base;
> > Descriptor->AddrRangeMax  = ResAllocNode->Base + ResAllocNode->Length - 
> > 1;
> > Descriptor->AddrLen   = ResAllocNode->Length;
> >+}
> > switch (ResAllocNode->Type) {
> >
> I think a more proper fix is to return EFI_UNSUPPORTED without returning any
> descriptors when the PcdPciDisableBusEnumeration is TRUE.
> Per UEFI Spec, EFI_UNSUPPORTED means "The current configuration of this PCI
> root bridge could not be retrieved." It's true when the PCD is true.
> 
> >
> >That leads to one last assert:
> >> QemuVideo: Cirrus 5446 detected
> >> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 7B9EF598
> >> Adding Mode 0 as Cirrus Internal Mode 0: 640x480, 32-bit, 60 Hz
> >> Adding Mode 1 as Cirrus Internal Mode 1: 800x600, 32-bit, 60 Hz
> >> Adding Mode 2 as Cirrus Internal Mode 2: 1024x768, 24-bit, 60 Hz
> >> PixelBlueGreenRedReserved8BitPerColor
> >> ASSERT 
> >> /local/home/sheep/work/ovmf/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c(1789): 
> >> ((BOOLEAN)(0==1))
> >For this one, I've workaround by reverting patch 7b0a1ea
> >(MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAttributes).
> >That issue was introduce while still using the USE_OLD_PCI_HOST.
> >
> >Any idee or pointer on how to fix those issues ?
> 
> When the PciRootBridgeIo.Configuration() returns EFI_UNSUPPORTED, this 
> assertion
> can be fixed as well. Correct?

I tried to make RootBridgeIoConfiguration() return EFI_UNSUPPORTED
(see the attachment), and those asserts were gone. However, the system
stuck somewhere after loading shell.efi. Here are the messages from the
debug log:

BdsLibConnectAll
Select Item: 0xE
Memory  Previous  CurrentNext
 TypePages Pages Pages
==      
  0A0004  0001  0004
  090008  0011  0015
  000004  0001  0004
  060024  0057  006C
  050030  0063  007B
  030180  048D  05B0
  040F00  0B65  0F00
Booting EFI Internal Shell
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 3EA580C0
Loading driver at 0x0003E03F000 EntryPoint=0x0003E03F240 Shell.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 3EA58B98
InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B 3EA54320
InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA 3EA53CD8

Re: [edk2] A logic error in OvmfPkg\SataControllerDxe\SataController.c

[Ni, Ruiyu]

Adding Laszlo & Jordan,
It sounds like a trivial bug.

Regards,
Ray

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of wang 
>xiaofeng
>Sent: Tuesday, April 26, 2016 3:02 PM
>To: Ni, Ruiyu 
>Cc: edk2-devel@lists.01.org
>Subject: [edk2] A logic error in OvmfPkg\SataControllerDxe\SataController.c
>
>Hi All ,
> I found a logic error in SataControllerStop of 
> OvmfPkg\SataControllerDxe\SataController.c.
>The following code will first free SataPrivateData ,then try to use 
> SataPrivateData
>
>
>if (SataPrivateData != NULL) {
>if (SataPrivateData->DisqualifiedModes != NULL) {
>  FreePool (SataPrivateData->DisqualifiedModes);
>}
>if (SataPrivateData->IdentifyData != NULL) {
>  FreePool (SataPrivateData->IdentifyData);
>}
>if (SataPrivateData->IdentifyValid != NULL) {
>  FreePool (SataPrivateData->IdentifyValid);
>}
>FreePool (SataPrivateData);
>  }
>
>
>  //
>  // Restore original PCI attributes
>  //
>  SataPrivateData->PciIo->Attributes (
>SataPrivateData->PciIo,
>EfiPciIoAttributeOperationSet,
>SataPrivateData->OriginalPciAttributes,
>NULL
>);
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [patch] MdeModulePkg/NvmExpressDxe: comments update to meet implementation

[Feng Tian]

Cc: Simon (Xiang) Lian-SSI 
Cc: Wu, Hao A 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian 
---
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
index 21c6255..6cbef3e 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
@@ -2,7 +2,7 @@
   NvmExpressDxe driver is used to manage non-volatile memory subsystem which 
follows
   NVM Express specification.
 
-  Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -101,13 +101,11 @@ struct _NVME_CONTROLLER_PRIVATE_DATA {
   NVME_ADMIN_CONTROLLER_DATA  *ControllerData;
 
   //
-  // 6 x 4kB aligned buffers will be carved out of this buffer.
+  // 4 x 4kB aligned buffers will be carved out of this buffer.
   // 1st 4kB boundary is the start of the admin submission queue.
-  // 2nd 4kB boundary is the start of the I/O submission queue #1.
-  // 3rd 4kB boundary is the start of the admin completion queue.
-  // 4th 4kB boundary is the start of the I/O completion queue #1.
-  // 5th 4kB boundary is the start of the first PRP list page.
-  // 6th 4kB boundary is the start of the second PRP list page.
+  // 2nd 4kB boundary is the start of the admin completion queue.
+  // 3rd 4kB boundary is the start of I/O submission queue #1.
+  // 4th 4kB boundary is the start of I/O completion queue #1.
   //
   UINT8   *Buffer;
   UINT8   *BufferPciAddr;
-- 
2.7.1.windows.2

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

Re: [edk2] [patch] MdeModulePkg/NvmExpressDxe: comments update to meet implementation

[Wu, Hao A]

Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

> -Original Message-
> From: Tian, Feng
> Sent: Tuesday, April 26, 2016 3:01 PM
> To: edk2-devel@lists.01.org
> Cc: Simon Lian-SSI; Wu; Wu, Hao A
> Subject: [patch] MdeModulePkg/NvmExpressDxe: comments update to meet
> implementation
> 
> Cc: Simon (Xiang) Lian-SSI 
> Cc: Wu, Hao A 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Feng Tian 
> ---
>  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
> index 21c6255..6cbef3e 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
> @@ -2,7 +2,7 @@
>NvmExpressDxe driver is used to manage non-volatile memory subsystem
> which follows
>NVM Express specification.
> 
> -  Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be 
> found
> at
> @@ -101,13 +101,11 @@ struct _NVME_CONTROLLER_PRIVATE_DATA {
>NVME_ADMIN_CONTROLLER_DATA  *ControllerData;
> 
>//
> -  // 6 x 4kB aligned buffers will be carved out of this buffer.
> +  // 4 x 4kB aligned buffers will be carved out of this buffer.
>// 1st 4kB boundary is the start of the admin submission queue.
> -  // 2nd 4kB boundary is the start of the I/O submission queue #1.
> -  // 3rd 4kB boundary is the start of the admin completion queue.
> -  // 4th 4kB boundary is the start of the I/O completion queue #1.
> -  // 5th 4kB boundary is the start of the first PRP list page.
> -  // 6th 4kB boundary is the start of the second PRP list page.
> +  // 2nd 4kB boundary is the start of the admin completion queue.
> +  // 3rd 4kB boundary is the start of I/O submission queue #1.
> +  // 4th 4kB boundary is the start of I/O completion queue #1.
>//
>UINT8   *Buffer;
>UINT8   *BufferPciAddr;
> --
> 2.7.1.windows.2

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

[edk2] [PATCH] SecurityPkg/DxeImageVerificationLib: Add DEBUG messages for image verification failures

[Cinnamon Shia]

Add DEBUG messages in DxeImageerificationLib to help debug Secure Boot image 
verification failures

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
Reviewed-by: Samer EL-Haj-Mahmoud 
---
 .../DxeImageVerificationLib.c  | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git 
a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c 
b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
index 4b4d3bf..4322aac 100644
--- a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
+++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
@@ -13,6 +13,7 @@
   untrusted PE/COFF image and validate its data structure within this image 
buffer before use.
 
 Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
+(C) Copyright 2016 Hewlett Packard Enterprise Development LP
 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
@@ -71,6 +72,8 @@ HASH_TABLE mHash[] = {
   { L"SHA512", 64, [32], 9, Sha512GetContextSize, Sha512Init, 
Sha512Update, Sha512Final}
 };
 
+EFI_STRING mHashTypeStr;
+
 /**
   SecureBoot Hook for processing image verification.
 
@@ -340,6 +343,7 @@ HashPeImage (
 return FALSE;
   }
 
+  mHashTypeStr = mHash[HashAlg].Name;
   CtxSize   = mHash[HashAlg].GetContextSize();
 
   HashCtx = AllocatePool (CtxSize);
@@ -1782,6 +1786,7 @@ ImageVerificationInAuditMode (
   UINT32   OffSet;
   CHAR16   *FilePathStr;
   UINTNSignatureListSize;
+  EFI_STATUS   VerifyStatus;
 
   SignatureList = NULL;
   WinCertificate= NULL;
@@ -1873,6 +1878,7 @@ ImageVerificationInAuditMode (
 //
 // The information can't be got from the invalid PeImage
 //
+DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid. Cannot 
retrieve image information.\n"));
 goto END;
   }
 
@@ -1896,6 +1902,7 @@ ImageVerificationInAuditMode (
 //
 // It is not a valid Pe/Coff file.
 //
+DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Not a valid PE/COFF 
image.\n"));
 Status = EFI_ACCESS_DENIED;
 goto END;
   }
@@ -1942,6 +1949,7 @@ ImageVerificationInAuditMode (
 // and not be reflected in the security data base "dbx".
 //
 if (!HashPeImage (HASHALG_SHA256)) {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Failed to hash this image 
using %s.\n", mHashTypeStr));
   Status = EFI_ACCESS_DENIED;
   goto END;
 }
@@ -1955,7 +1963,14 @@ ImageVerificationInAuditMode (
   //
   if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
mImageDigest, , mImageDigestSize)) {
 Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
EFI_IMAGE_EXECUTION_INITIALIZED;
+  } else {
+//
+// Image Hash is not in DB/DBX
+//
+DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not signed and 
%s hash of image is not found in DB/DBX.\n", mHashTypeStr));
   }
+} else {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is not signed and 
%s hash of image is rejected by DBX.\n", mHashTypeStr));
 }
 
 //
@@ -2029,7 +2044,11 @@ ImageVerificationInAuditMode (
 // Check the digital signature against the valid certificate in allowed 
database (db).
 //
 if (!IsForbiddenByDbx (AuthData, AuthDataSize, TRUE, FilePathStr, File)) {
-  IsAllowedByDb (AuthData, AuthDataSize, TRUE, FilePathStr, File);
+  if (IsAllowedByDb (AuthData, AuthDataSize, TRUE, FilePathStr, File)) {
+VerifyStatus = EFI_SUCCESS;
+  }
+} else {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is signed but 
signature is rejected by DBX.\n"));
 }
 
 //
@@ -2038,7 +2057,13 @@ ImageVerificationInAuditMode (
 if (!IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE1, 
mImageDigest, , mImageDigestSize)) {
   if (IsSignatureFoundInDatabase (EFI_IMAGE_SECURITY_DATABASE, 
mImageDigest, , mImageDigestSize)) {
 Action = EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED | 
EFI_IMAGE_EXECUTION_INITIALIZED; 
+  } else {
+if (VerifyStatus != EFI_SUCCESS) {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is signed but 
signature and %s hash of image are not found in DB/DBX.\n", mHashTypeStr));
+}
   }
+} else {
+  DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: Image is signed but %s 
hash of image is rejected by DBX.\n", mHashTypeStr));
 }
 
 //
@@ -2259,6 +2284,7 @@ DxeImageVerificationHandler (
 //
 // The information can't be got from the invalid PeImage
 //
+DEBUG ((DEBUG_ERROR, "DxeImageVerificationLib: PeImage invalid. Cannot 
retrieve image 

[edk2] A logic error in OvmfPkg\SataControllerDxe\SataController.c

[wang xiaofeng]

Hi All ,
 I found a logic error in SataControllerStop of 
OvmfPkg\SataControllerDxe\SataController.c.
The following code will first free SataPrivateData ,then try to use 
SataPrivateData


if (SataPrivateData != NULL) {
if (SataPrivateData->DisqualifiedModes != NULL) {
  FreePool (SataPrivateData->DisqualifiedModes);
}
if (SataPrivateData->IdentifyData != NULL) {
  FreePool (SataPrivateData->IdentifyData);
}
if (SataPrivateData->IdentifyValid != NULL) {
  FreePool (SataPrivateData->IdentifyValid);
}
FreePool (SataPrivateData);
  }


  //
  // Restore original PCI attributes
  //
  SataPrivateData->PciIo->Attributes (
SataPrivateData->PciIo,
EfiPciIoAttributeOperationSet,
SataPrivateData->OriginalPciAttributes,
NULL
);
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] OVMF broken under Xen (in PCI initialisation)

[Ni, Ruiyu]

Gary,
thanks for providing the quick fix. How about directly return
EFI_UNSUPPORTED when the PcdPciDisableEnumeration is TRUE?
See my another mail reply to this thread.

Regards,
Ray

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gary Lin
>Sent: Tuesday, April 26, 2016 2:29 PM
>To: Anthony PERARD ; Ni, Ruiyu 
>Cc: edk2-de...@ml01.01.org; Laszlo Ersek ; Xen Devel 
>
>Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>
>On Mon, Apr 25, 2016 at 01:43:01PM +0200, Laszlo Ersek wrote:
>> On 04/22/16 16:47, Anthony PERARD wrote:
>> > Hi,
>> >
>> > Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root
>> > bridge does not finish to initialize and breaks under Xen.
>>
>> (Adding Ray Ni)
>>
>> > There are several issue probably due to the use of
>> > PcdPciDisableBusEnumeration=TRUE.
>> >
>> > First one:
>> > ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): 
>> > Bridge->Mem.Limit <
>0x0001ULL
>> >
>> > This patch would fix the first assert:
>> > diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
>> > index 7fa9019..15ec7a7 100644
>> > --- a/OvmfPkg/PlatformPei/Xen.c
>> > +++ b/OvmfPkg/PlatformPei/Xen.c
>> > @@ -227,5 +227,11 @@ InitializeXen (
>> >
>> >PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
>> >
>> > +  // Values from hvmloader
>> > +#define PCI_MEM_END 0xFC00
>> > +#define HVM_BELOW_4G_MMIO_START 0xF000
>> > +  PcdSet64 (PcdPciMmio32Base, HVM_BELOW_4G_MMIO_START);
>> > +  PcdSet64 (PcdPciMmio32Size, PCI_MEM_END - HVM_BELOW_4G_MMIO_START);
>> > +
>> >return EFI_SUCCESS;
>> >  }
>>
>> For this, I am to blame; sorry about the regression. Can you please
>> submit the change as a standalone patch, and mention commit
>> 03845e90cc432 as the one that missed it?
>>
>> Also, can you please add the macros to "OvmfPkg/PlatformPei/Xen.h"
>> instead, near OVMF_INFO_PHYSICAL_ADDRESS?
>>
>> >
>> >
>> > But that not enough, next assert is:
>> > ASSERT MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c(807): RootBridge 
>> > != ((void *) 0)
>> >
>> > I have worked around this one with the following patch. That would
>> > correspond to how the former implementation in OvmfPkg was initializing the
>> > struct. Maybe a better way would be to fill ResAllocated under Xen,
>> > somehow. Under Xen, the ResAllocNode status is not allocated, so no
>> > Descriptor are created.
>> >
>> > diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> > index cda9b49..eda92b6 100644
>> > --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> > +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> > @@ -1509,15 +1509,13 @@ RootBridgeIoConfiguration (
>> >
>> >  ResAllocNode = >ResAllocNode[Index];
>> >
>> > -if (ResAllocNode->Status != ResAllocated) {
>> > -  continue;
>> > -}
>> > -
>> >  Descriptor->Desc = ACPI_ADDRESS_SPACE_DESCRIPTOR;
>> >  Descriptor->Len  = sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) - 3;
>> > +if (ResAllocNode->Status != ResAllocated) {
>> >  Descriptor->AddrRangeMin  = ResAllocNode->Base;
>> >  Descriptor->AddrRangeMax  = ResAllocNode->Base + ResAllocNode->Length 
>> > - 1;
>> >  Descriptor->AddrLen   = ResAllocNode->Length;
>> > +}
>> >  switch (ResAllocNode->Type) {
>> >
>> >
>> > That leads to one last assert:
>> >> QemuVideo: Cirrus 5446 detected
>> >> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 7B9EF598
>> >> Adding Mode 0 as Cirrus Internal Mode 0: 640x480, 32-bit, 60 Hz
>> >> Adding Mode 1 as Cirrus Internal Mode 1: 800x600, 32-bit, 60 Hz
>> >> Adding Mode 2 as Cirrus Internal Mode 2: 1024x768, 24-bit, 60 Hz
>> >> PixelBlueGreenRedReserved8BitPerColor
>> >> ASSERT 
>> >> /local/home/sheep/work/ovmf/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c(1789): 
>> >> ((BOOLEAN)(0==1))
>> > For this one, I've workaround by reverting patch 7b0a1ea
>> > (MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAttributes).
>> > That issue was introduce while still using the USE_OLD_PCI_HOST.
>> >
>> > Any idee or pointer on how to fix those issues ?
>>
>> I think your suggestion that PcdPciDisableBusEnumeration=TRUE causes
>> these problems is likely correct. Both of the above issues seem to
>> originate from PciHostBridgeDxe's assumption that resources have been
>> allocated (i.e., there has been an enumeration).
>>
>> Please discuss these questions with Ray -- I guess PciHostBridgeDxe may
>> not have received a lot of testing with
>> PcdPciDisableBusEnumeration=TRUE. I can imagine that simply considering
>> PcdPciDisableBusEnumeration, and acting conditionally upon its value,
>> might solve these problems.
>>
>I made a quick fix to skip those checks when PcdPciDisableBusEnumeration
>is TRUE. Plus the fix for 

Re: [edk2] OVMF broken under Xen (in PCI initialisation)

[Ni, Ruiyu]

Regards,
Ray

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Anthony 
>PERARD
>Sent: Friday, April 22, 2016 10:48 PM
>To: edk2-devel@lists.01.org
>Cc: Xen Devel 
>Subject: [edk2] OVMF broken under Xen (in PCI initialisation)
>
>Hi,
>
>Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root
>bridge does not finish to initialize and breaks under Xen.
>
>There are several issue probably due to the use of
>PcdPciDisableBusEnumeration=TRUE.
>
>First one:
>ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): 
>Bridge->Mem.Limit < 0x0001ULL
>
>This patch would fix the first assert:
>diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
>index 7fa9019..15ec7a7 100644
>--- a/OvmfPkg/PlatformPei/Xen.c
>+++ b/OvmfPkg/PlatformPei/Xen.c
>@@ -227,5 +227,11 @@ InitializeXen (
>
>   PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
>
>+  // Values from hvmloader
>+#define PCI_MEM_END 0xFC00
>+#define HVM_BELOW_4G_MMIO_START 0xF000
>+  PcdSet64 (PcdPciMmio32Base, HVM_BELOW_4G_MMIO_START);
>+  PcdSet64 (PcdPciMmio32Size, PCI_MEM_END - HVM_BELOW_4G_MMIO_START);
>+
>   return EFI_SUCCESS;
> }
>
>
>But that not enough, next assert is:
>ASSERT MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c(807): RootBridge != 
>((void *) 0)
>
>I have worked around this one with the following patch. That would
>correspond to how the former implementation in OvmfPkg was initializing the
>struct. Maybe a better way would be to fill ResAllocated under Xen,
>somehow. Under Xen, the ResAllocNode status is not allocated, so no
>Descriptor are created.
>
>diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>index cda9b49..eda92b6 100644
>--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>@@ -1509,15 +1509,13 @@ RootBridgeIoConfiguration (
>
> ResAllocNode = >ResAllocNode[Index];
>
>-if (ResAllocNode->Status != ResAllocated) {
>-  continue;
>-}
>-
> Descriptor->Desc = ACPI_ADDRESS_SPACE_DESCRIPTOR;
> Descriptor->Len  = sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) - 3;
>+if (ResAllocNode->Status != ResAllocated) {
> Descriptor->AddrRangeMin  = ResAllocNode->Base;
> Descriptor->AddrRangeMax  = ResAllocNode->Base + ResAllocNode->Length - 1;
> Descriptor->AddrLen   = ResAllocNode->Length;
>+}
> switch (ResAllocNode->Type) {
>
I think a more proper fix is to return EFI_UNSUPPORTED without returning any
descriptors when the PcdPciDisableBusEnumeration is TRUE.
Per UEFI Spec, EFI_UNSUPPORTED means "The current configuration of this PCI
root bridge could not be retrieved." It's true when the PCD is true.

>
>That leads to one last assert:
>> QemuVideo: Cirrus 5446 detected
>> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 7B9EF598
>> Adding Mode 0 as Cirrus Internal Mode 0: 640x480, 32-bit, 60 Hz
>> Adding Mode 1 as Cirrus Internal Mode 1: 800x600, 32-bit, 60 Hz
>> Adding Mode 2 as Cirrus Internal Mode 2: 1024x768, 24-bit, 60 Hz
>> PixelBlueGreenRedReserved8BitPerColor
>> ASSERT 
>> /local/home/sheep/work/ovmf/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c(1789): 
>> ((BOOLEAN)(0==1))
>For this one, I've workaround by reverting patch 7b0a1ea
>(MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAttributes).
>That issue was introduce while still using the USE_OLD_PCI_HOST.
>
>Any idee or pointer on how to fix those issues ?

When the PciRootBridgeIo.Configuration() returns EFI_UNSUPPORTED, this assertion
can be fixed as well. Correct?
>
>Thanks,
>
>--
>Anthony PERARD
>___
>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] OVMF broken under Xen (in PCI initialisation)

[Gary Lin]

On Mon, Apr 25, 2016 at 01:43:01PM +0200, Laszlo Ersek wrote:
> On 04/22/16 16:47, Anthony PERARD wrote:
> > Hi,
> > 
> > Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root
> > bridge does not finish to initialize and breaks under Xen.
> 
> (Adding Ray Ni)
> 
> > There are several issue probably due to the use of
> > PcdPciDisableBusEnumeration=TRUE.
> > 
> > First one:
> > ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): 
> > Bridge->Mem.Limit < 0x0001ULL
> > 
> > This patch would fix the first assert:
> > diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
> > index 7fa9019..15ec7a7 100644
> > --- a/OvmfPkg/PlatformPei/Xen.c
> > +++ b/OvmfPkg/PlatformPei/Xen.c
> > @@ -227,5 +227,11 @@ InitializeXen (
> > 
> >PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
> > 
> > +  // Values from hvmloader
> > +#define PCI_MEM_END 0xFC00
> > +#define HVM_BELOW_4G_MMIO_START 0xF000
> > +  PcdSet64 (PcdPciMmio32Base, HVM_BELOW_4G_MMIO_START);
> > +  PcdSet64 (PcdPciMmio32Size, PCI_MEM_END - HVM_BELOW_4G_MMIO_START);
> > +
> >return EFI_SUCCESS;
> >  }
> 
> For this, I am to blame; sorry about the regression. Can you please
> submit the change as a standalone patch, and mention commit
> 03845e90cc432 as the one that missed it?
> 
> Also, can you please add the macros to "OvmfPkg/PlatformPei/Xen.h"
> instead, near OVMF_INFO_PHYSICAL_ADDRESS?
> 
> > 
> > 
> > But that not enough, next assert is:
> > ASSERT MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c(807): RootBridge 
> > != ((void *) 0)
> > 
> > I have worked around this one with the following patch. That would
> > correspond to how the former implementation in OvmfPkg was initializing the
> > struct. Maybe a better way would be to fill ResAllocated under Xen,
> > somehow. Under Xen, the ResAllocNode status is not allocated, so no
> > Descriptor are created.
> > 
> > diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c 
> > b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> > index cda9b49..eda92b6 100644
> > --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> > +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> > @@ -1509,15 +1509,13 @@ RootBridgeIoConfiguration (
> > 
> >  ResAllocNode = >ResAllocNode[Index];
> > 
> > -if (ResAllocNode->Status != ResAllocated) {
> > -  continue;
> > -}
> > -
> >  Descriptor->Desc = ACPI_ADDRESS_SPACE_DESCRIPTOR;
> >  Descriptor->Len  = sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) - 3;
> > +if (ResAllocNode->Status != ResAllocated) {
> >  Descriptor->AddrRangeMin  = ResAllocNode->Base;
> >  Descriptor->AddrRangeMax  = ResAllocNode->Base + ResAllocNode->Length 
> > - 1;
> >  Descriptor->AddrLen   = ResAllocNode->Length;
> > +}
> >  switch (ResAllocNode->Type) {
> > 
> > 
> > That leads to one last assert:
> >> QemuVideo: Cirrus 5446 detected
> >> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 7B9EF598
> >> Adding Mode 0 as Cirrus Internal Mode 0: 640x480, 32-bit, 60 Hz
> >> Adding Mode 1 as Cirrus Internal Mode 1: 800x600, 32-bit, 60 Hz
> >> Adding Mode 2 as Cirrus Internal Mode 2: 1024x768, 24-bit, 60 Hz
> >> PixelBlueGreenRedReserved8BitPerColor
> >> ASSERT 
> >> /local/home/sheep/work/ovmf/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c(1789): 
> >> ((BOOLEAN)(0==1))
> > For this one, I've workaround by reverting patch 7b0a1ea
> > (MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAttributes).
> > That issue was introduce while still using the USE_OLD_PCI_HOST.
> > 
> > Any idee or pointer on how to fix those issues ?
> 
> I think your suggestion that PcdPciDisableBusEnumeration=TRUE causes
> these problems is likely correct. Both of the above issues seem to
> originate from PciHostBridgeDxe's assumption that resources have been
> allocated (i.e., there has been an enumeration).
> 
> Please discuss these questions with Ray -- I guess PciHostBridgeDxe may
> not have received a lot of testing with
> PcdPciDisableBusEnumeration=TRUE. I can imagine that simply considering
> PcdPciDisableBusEnumeration, and acting conditionally upon its value,
> might solve these problems.
> 
I made a quick fix to skip those checks when PcdPciDisableBusEnumeration
is TRUE. Plus the fix for OvmfPkg/PlatformPei/Xen.c, I can now boot to
the UEFI shell.

Ray,

Do you think this is the right way to fix it?

Thanks,

Gary Lin
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
index f72598d..0fb150c 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
@@ -1824,6 +1824,7 @@ PciIoGetBarAttributes (
   PCI_IO_DEVICE *PciIoDevice;
   EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Descriptor;
   EFI_ACPI_END_TAG_DESCRIPTOR   *End;
+  BOOLEAN   EnablePciEnumeration;
 
   PciIoDevice = PCI_IO_DEVICE_FROM_PCI_IO_THIS (This);
 
@@ -1918,7 

Re: [edk2] [Patch] BaseTools: Update FMP Capsule support to follow FDF spec

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yonghong Zhu
> Sent: Thursday, April 21, 2016 3:08 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming
> Subject: [edk2] [Patch] BaseTools: Update FMP Capsule support to follow
> FDF spec
> 
> Current the FMP Capsule feature is supported, but its format has a little
> different with FDF spec. so this patch 1) Align the FMP Capsule with FDF
> spec. 2) fix some style issue, eg: Tab. 3) Add a SectionParser function to
> check the section header info since this method is used in 7 places.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/GenFds/FdfParser.py | 60 --
> ---
>  1 file changed, 34 insertions(+), 26 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py
> b/BaseTools/Source/Python/GenFds/FdfParser.py
> index 28af09b..72fb3dc 100644
> --- a/BaseTools/Source/Python/GenFds/FdfParser.py
> +++ b/BaseTools/Source/Python/GenFds/FdfParser.py
> @@ -53,11 +53,10 @@ from Common.Expression import *
>  from Common import GlobalData
>  from Common.String import ReplaceMacro
> 
>  from Common.Misc import tdict
> 
> -import re
>  import Common.LongFilePathOs as os
>  from Common.LongFilePathSupport import OpenLongFilePath as open
> 
>  ##define T_CHAR_SPACE' '
>  ##define T_CHAR_NULL '\0'
> @@ -104,11 +103,11 @@ def GetRealFileLine (File, Line):
>  InsertedLines = 0
>  for Profile in AllIncludeFileList:
>  if Profile.IsLineInFile(Line):
>  return Profile.GetLineInFile(Line)
>  elif Line >= Profile.InsertStartLineNumber and Profile.Level == 1:
> -   InsertedLines += Profile.GetTotalLines()
> +InsertedLines += Profile.GetTotalLines()
> 
>  return (File, Line - InsertedLines)
> 
>  ## The exception class that used to report error messages when parsing FDF
>  #
> @@ -179,11 +178,11 @@ class IncludeFileProfile :
> 
>  def GetTotalLines(self):
>  TotalLines = self.InsertAdjust + len(self.FileLinesList)
> 
>  for Profile in self.IncludeFileList:
> -  TotalLines += Profile.GetTotalLines()
> +TotalLines += Profile.GetTotalLines()
> 
>  return TotalLines
> 
>  def IsLineInFile(self, Line):
>  if Line >= self.InsertStartLineNumber and Line <
> self.InsertStartLineNumber + self.GetTotalLines():
> @@ -1396,10 +1395,24 @@ class FdfParser:
>  FileLineTuple = GetRealFileLine(self.FileName,
> self.CurrentLineNumber)
>  X.Message += ' near line %d, column %d: %s' \
>  % (FileLineTuple[1], self.CurrentOffsetWithinLine + 1,
> self.Profile.FileLinesList[self.CurrentLineNumber -
> 1][self.CurrentOffsetWithinLine :].rstrip('\n').rstrip('\r'))
>  raise
> 
> +## SectionParser() method
> +#
> +#   Parse the file section info
> +#   Exception will be raised if syntax error found
> +#
> +#   @param  self  The object pointer
> +#   @param  section   The section string
> +
> +def SectionParser(self, section):
> +S = section.upper()
> +if not S.startswith("[DEFINES") and not S.startswith("[FD.") and not
> S.startswith("[FV.") and not S.startswith("[CAPSULE.") \
> +and not S.startswith("[VTF.") and not S.startswith("[RULE.") and 
> not
> S.startswith("[OPTIONROM.") and not S.startswith('[FMPPAYLOAD.'):
> +raise Warning("Unknown section or section appear sequence error
> (The correct sequence should be [DEFINES], [FD.], [FV.], [Capsule.], [VTF.],
> [Rule.], [OptionRom.], [FMPPAYLOAD.])", self.FileName,
> self.CurrentLineNumber)
> +
>  ## __GetDefines() method
>  #
>  #   Get Defines section contents and store its data into AllMacrosList
>  #
>  #   @param  selfThe object pointer
> @@ -1411,13 +1424,11 @@ class FdfParser:
>  if not self.__GetNextToken():
>  return False
> 
>  S = self.__Token.upper()
>  if S.startswith("[") and not S.startswith("[DEFINES"):
> -if not S.startswith("[FD.") and not S.startswith("[FV.") and not
> S.startswith("[CAPSULE.") \
> -and not S.startswith("[VTF.") and not S.startswith("[RULE.") 
> and not
> S.startswith("[OPTIONROM."):
> -raise Warning("Unknown section or section appear sequence 
> error
> (The correct sequence should be [DEFINES], [FD.], [FV.], [Capsule.], [VTF.],
> [Rule.], [OptionRom.])", self.FileName, self.CurrentLineNumber)
> +self.SectionParser(S)
>  self.__UndoToken()
>  return False
> 
>  self.__UndoToken()
>  if not self.__IsToken("[DEFINES", True):
> @@ -2106,13 +2117,11 @@ class FdfParser:
>  if not 

Re: [edk2] [Patch] BaseTools: Fix the bug for .aml to use ASL binary type in Asbuilt inf

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Zhu, Yonghong
> Sent: Friday, April 22, 2016 3:18 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming
> Subject: [Patch] BaseTools: Fix the bug for .aml to use ASL binary type in
> Asbuilt inf
> 
> Per build spec, the .aml file should use ASL binary type in the Asbuilt
> inf file. the original bug is .aml file may use BIN as binary type when
> the module type is not BASE or USER_DEFINED. This patch 1) fix this bug.
> 2) fix some indent coding style issue.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/AutoGen/AutoGen.py | 37 +--
> ---
>  1 file changed, 16 insertions(+), 21 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
> b/BaseTools/Source/Python/AutoGen/AutoGen.py
> index 2cc6970..ae0f8a6 100644
> --- a/BaseTools/Source/Python/AutoGen/AutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
> @@ -1113,11 +1113,11 @@ class PlatformAutoGen(AutoGen):
>  self.IsCodeFileCreated = True
> 
>  ## Generate Fds Command
>  def _GenFdsCommand(self):
>  return self.Workspace.GenFdsCommand
> -
> +
>  ## Create makefile for the platform and mdoules in it
>  #
>  #   @param  CreateModuleMakeFileFlag indicating if the makefile 
> for
>  #   modules will be created as well
>  #
> @@ -3664,38 +3664,33 @@ class ModuleAutoGen(AutoGen):
> 
>  if DriverType:
>  AsBuiltInfDict['pcd_is_driver_string'] += [DriverType]
> 
>  if 'UEFI_SPECIFICATION_VERSION' in self.Specification:
> -  AsBuiltInfDict['module_uefi_specification_version'] +=
> [self.Specification['UEFI_SPECIFICATION_VERSION']]
> +AsBuiltInfDict['module_uefi_specification_version'] +=
> [self.Specification['UEFI_SPECIFICATION_VERSION']]
>  if 'PI_SPECIFICATION_VERSION' in self.Specification:
> -  AsBuiltInfDict['module_pi_specification_version'] +=
> [self.Specification['PI_SPECIFICATION_VERSION']]
> +AsBuiltInfDict['module_pi_specification_version'] +=
> [self.Specification['PI_SPECIFICATION_VERSION']]
> 
>  OutputDir = self.OutputDir.replace('\\', '/').strip('/')
> -if self.ModuleType in ['BASE', 'USER_DEFINED']:
> -  for Item in self.CodaTargetList:
> +
> +for Item in self.CodaTargetList:
>  File = Item.Target.Path.replace('\\', 
> '/').strip('/').replace(OutputDir,
> '').strip('/')
>  if Item.Target.Ext.lower() == '.aml':
> -  AsBuiltInfDict['binary_item'] += ['ASL|' + File]
> +AsBuiltInfDict['binary_item'] += ['ASL|' + File]
>  elif Item.Target.Ext.lower() == '.acpi':
> -  AsBuiltInfDict['binary_item'] += ['ACPI|' + File]
> -else:
> -  AsBuiltInfDict['binary_item'] += ['BIN|' + File]
> -else:
> -  for Item in self.CodaTargetList:
> -File = Item.Target.Path.replace('\\', 
> '/').strip('/').replace(OutputDir,
> '').strip('/')
> -if Item.Target.Ext.lower() == '.efi':
> -  AsBuiltInfDict['binary_item'] += ['PE32|' + self.Name + '.efi']
> +AsBuiltInfDict['binary_item'] += ['ACPI|' + File]
> +elif Item.Target.Ext.lower() == '.efi':
> +AsBuiltInfDict['binary_item'] += ['PE32|' + self.Name + 
> '.efi']
>  else:
> -  AsBuiltInfDict['binary_item'] += ['BIN|' + File]
> -  if self.DepexGenerated:
> +AsBuiltInfDict['binary_item'] += ['BIN|' + File]
> +if self.DepexGenerated:
>  if self.ModuleType in ['PEIM']:
> -  AsBuiltInfDict['binary_item'] += ['PEI_DEPEX|' + self.Name + 
> '.depex']
> +AsBuiltInfDict['binary_item'] += ['PEI_DEPEX|' + self.Name +
> '.depex']
>  if self.ModuleType in ['DXE_DRIVER', 'DXE_RUNTIME_DRIVER',
> 'DXE_SAL_DRIVER', 'UEFI_DRIVER']:
> -  AsBuiltInfDict['binary_item'] += ['DXE_DEPEX|' + self.Name + 
> '.depex']
> +AsBuiltInfDict['binary_item'] += ['DXE_DEPEX|' + self.Name +
> '.depex']
>  if self.ModuleType in ['DXE_SMM_DRIVER']:
> -  AsBuiltInfDict['binary_item'] += ['SMM_DEPEX|' + self.Name +
> '.depex']
> +AsBuiltInfDict['binary_item'] += ['SMM_DEPEX|' + self.Name +
> '.depex']
> 
>  Bin = self._GenOffsetBin()
>  if Bin:
>  AsBuiltInfDict['binary_item'] += ['BIN|%s' % Bin]
> 
> @@ -3843,12 +3838,12 @@ class ModuleAutoGen(AutoGen):
>  PcdEntry = Pcd.TokenSpaceGuidCName + '.' + TokenCName
>  if PcdComments:
>  PcdEntry = PcdComments + '\n  ' + PcdEntry
>  AsBuiltInfDict['pcd_item'] += [PcdEntry]
>  for Item in self.BuildOption:
> -