Re: [edk2] [Patch] UefiCpuPkg/RegisterCpuFeaturesLib: Fix build failure.

2018-10-29 Thread Ni, Ruiyu
Reviewed-by: Ruiyu Ni 

Thanks/Ray

> -Original Message-
> From: Dong, Eric
> Sent: Tuesday, October 30, 2018 11:05 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan ; Ni, Ruiyu 
> Subject: [Patch] UefiCpuPkg/RegisterCpuFeaturesLib: Fix build failure.
> 
> Build UefiCpuPkg with below configuration:
> Architecture(s)  = IA32
> Build target = NOOPT
> Toolchain= VS2015x86
> 
> Below error info shows up:
> DxeRegisterCpuFeaturesLib.lib(CpuFeaturesInitialize.obj) :
> error LNK2001: unresolved external symbol __allmul
> 
> Valid mDependTypeStr type only have 5 items, use UINT32 type cast to fix
> this error.
> 
> Cc: Dandan Bi 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> index bc372a338f..8588800e4a 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> @@ -517,7 +517,7 @@ DumpRegisterTableOnProcessor (
>  DebugPrintErrorLevel,
>  "Processor: %d: Semaphore: Scope Value: %s\r\n",
>  ProcessorNumber,
> -mDependTypeStr[MIN (RegisterTableEntry->Value, InvalidDepType)]
> +mDependTypeStr[MIN ((UINT32)RegisterTableEntry->Value,
> + InvalidDepType)]
>  ));
>break;
> 
> --
> 2.15.0.windows.1

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


[edk2] [Patch] UefiCpuPkg/RegisterCpuFeaturesLib: Fix build failure.

2018-10-29 Thread Eric Dong
Build UefiCpuPkg with below configuration:
Architecture(s)  = IA32
Build target = NOOPT
Toolchain= VS2015x86

Below error info shows up:
DxeRegisterCpuFeaturesLib.lib(CpuFeaturesInitialize.obj) :
error LNK2001: unresolved external symbol __allmul

Valid mDependTypeStr type only have 5 items, use UINT32 type cast
to fix this error.

Cc: Dandan Bi 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
index bc372a338f..8588800e4a 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
@@ -517,7 +517,7 @@ DumpRegisterTableOnProcessor (
 DebugPrintErrorLevel,
 "Processor: %d: Semaphore: Scope Value: %s\r\n",
 ProcessorNumber,
-mDependTypeStr[MIN (RegisterTableEntry->Value, InvalidDepType)]
+mDependTypeStr[MIN ((UINT32)RegisterTableEntry->Value, InvalidDepType)]
 ));
   break;
 
-- 
2.15.0.windows.1

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


Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain support

2018-10-29 Thread Wang, Jian J
Mike,

Since we're pending on the documentation of those APIs and it seems it won't
be solved soon, I'd suggest to drop this feature from the coming release event.

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning

Regards,
Jian

> -Original Message-
> From: Kinney, Michael D
> Sent: Friday, October 19, 2018 7:17 AM
> To: Wang, Jian J ; Gao, Liming ;
> edk2-devel@lists.01.org; Kinney, Michael D 
> Cc: Yao, Jiewen ; Andrew Fish 
> Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain
> support
> 
> Jian,
> 
> I do not see a description of the parameters, return
> values or required behavior for those APIs in the header
> files.  How do you know if they are implemented correctly?
> 
> How would we write tests for these APIs?
> 
> Mike
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Wednesday, October 17, 2018 7:16 PM
> > To: Kinney, Michael D ; Gao,
> > Liming ; edk2-devel  > boun...@lists.01.org>; edk2-devel@lists.01.org
> > Cc: Yao, Jiewen ; Andrew Fish
> > 
> > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add
> > MSFT toolchain support
> >
> > Mike,
> >
> > All those functions are declared in source files in
> > Visual Studio except to
> > __GSHandlerCheck(). But I can't find there's online link
> > or document to those files
> > and APIs. Is it ok to just list the file names?
> >
> > VC\INCLUDE\vcruntime.h:
> > __security_check_cookie
> > __report_gsfailure
> >
> > VC\INCLUDE\rtcapi.h:
> > _RTC_CheckEsp
> > _RTC_CheckStackVars
> > _RTC_Shutdown
> > _RTC_InitBase
> >
> > VC\crt\src\vcruntime\gs_report.c
> > __report_rangecheckfailure
> >
> > I built the lib with all supported VS toolchains and all
> > passed, but only tested
> > with VS2015. I think I need to do more tests. Thanks for
> > pointing it out.
> >
> > Regards,
> > Jian
> >
> >
> > > -Original Message-
> > > From: Kinney, Michael D
> > > Sent: Thursday, October 18, 2018 9:36 AM
> > > To: Gao, Liming ; Wang, Jian J
> > ;
> > > edk2-devel ; edk2-
> > de...@lists.01.org;
> > > Kinney, Michael D 
> > > Cc: Yao, Jiewen ; Andrew Fish
> > 
> > > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib:
> > add MSFT toolchain
> > > support
> > >
> > > Jian,
> > >
> > > Is there a link to the documentation for these new
> > > functions?  We should put the link in the file
> > > headers.
> > >
> > > The link to docs should also be added to the BZ.
> > >
> > > Also, which VS compilers was this tested with?  Are
> > > different implementations required for different VS
> > > compilers?
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: Gao, Liming
> > > > Sent: Wednesday, October 17, 2018 6:22 PM
> > > > To: Wang, Jian J ; edk2-devel
> > > > ; edk2-
> > > > de...@lists.01.org
> > > > Cc: Kinney, Michael D ;
> > Yao,
> > > > Jiewen ; Andrew Fish
> > > > 
> > > > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib:
> > add
> > > > MSFT toolchain support
> > > >
> > > > Jian:
> > > >   The patch is good to me. Reviewed-by: Liming Gao
> > > > 
> > > >
> > > > Thanks
> > > > Liming
> > > > >-Original Message-
> > > > >From: Wang, Jian J
> > > > >Sent: Thursday, October 18, 2018 9:19 AM
> > > > >To: edk2-devel ;
> > edk2-
> > > > de...@lists.01.org
> > > > >Cc: Kinney, Michael D ;
> > Yao,
> > > > Jiewen
> > > > >; Andrew Fish
> > ;
> > > > Gao, Liming
> > > > >
> > > > >Subject: RE: [edk2] [PATCH]
> > MdePkg/BaseStackCheckLib:
> > > > add MSFT toolchain
> > > > >support
> > > > >
> > > > >Ping ... :)
> > > > >
> > > > >Regards,
> > > > >Jian
> > > > >
> > > > >
> > > > >> -Original Message-
> > > > >> From: edk2-devel [mailto:edk2-devel-
> > > > boun...@lists.01.org]
> > > > >> Sent: Tuesday, October 16, 2018 8:59 AM
> > > > >> To: edk2-devel ;
> > > > edk2-
> > > > >de...@lists.01.org
> > > > >> Cc: Kinney, Michael D
> > ;
> > > > Yao, Jiewen
> > > > >> ; Andrew Fish
> > ;
> > > > Gao, Liming
> > > > >> 
> > > > >> Subject: Re: [edk2] [PATCH]
> > MdePkg/BaseStackCheckLib:
> > > > add MSFT
> > > > >toolchain
> > > > >> support
> > > > >>
> > > > >> REF:
> > > > https://bugzilla.tianocore.org/show_bug.cgi?id=1239
> > > > >>
> > > > >> Regards,
> > > > >> Jian
> > > > >>
> > > > >>
> > > > >> > -Original Message-
> > > > >> > From: edk2-devel [mailto:edk2-devel-
> > > > boun...@lists.01.org]
> > > > >> > Sent: Tuesday, October 16, 2018 8:55 AM
> > > > >> > To: edk2-devel@lists.01.org
> > > > >> > Cc: Kinney, Michael D
> > ;
> > > > Yao, Jiewen
> > > > >> > ; Andrew Fish
> > > > ; Gao, Liming
> > > > >> > 
> > > > >> > Subject: [edk2] [PATCH]
> > MdePkg/BaseStackCheckLib:
> > > > add MSFT toolchain
> > > > >> > support
> > > > >> >
> > > > >> > This patch adds stack check support for MSFT
> > > > toolchain, with
> > > > >> > compiler option /GS and /RTCs. This
> > functionality is
> > > > similar
> > > > >> > to the original ones supported by GCC toolchain.
> > > > >> >
> > > > >> > Usage example:
> > > 

[edk2] [PATCH v3] MdeModulePkg/PiSmmIpl: Do not reset SMRAM to UC when CPU driver runs

2018-10-29 Thread Ruiyu Ni
Today's PiSmmIpl implementation initially sets SMRAM to WB to speed
up the SMM core/modules loading before SMM CPU driver runs.
When SMM CPU driver runs, PiSmmIpl resets the SMRAM to UC. It's done
in SmmIplDxeDispatchEventNotify(). COMM_BUFFER_SMM_DISPATCH_RESTART
is returned from SMM core that SMM CPU driver is just dispatched.

Since now the SMRR is widely used to control the SMRAM cache setting.
It's not needed to reset the SMRAM to UC anymore.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Jiewen Yao 
Cc: Michael Kinney 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
index f8cbe1704b..2fb877127b 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
@@ -672,21 +672,10 @@ SmmIplDxeDispatchEventNotify (
   return;
 }
 
-//
-// Attempt to reset SMRAM cacheability to UC
-// Assume CPU AP is available at this time
-//
-Status = gDS->SetMemorySpaceAttributes(
-mSmramCacheBase,
-mSmramCacheSize,
-EFI_MEMORY_UC
-);
-if (EFI_ERROR (Status)) {
-  DEBUG ((DEBUG_WARN, "SMM IPL failed to reset SMRAM window to 
EFI_MEMORY_UC\n"));
-}
-
 //
 // Close all SMRAM ranges to protect SMRAM
+// NOTE: SMRR is enabled by CPU SMM driver by calling 
SmmCpuFeaturesInitializeProcessor() from SmmCpuFeaturesLib
+//   so no need to reset the SMRAM to UC in MTRR.
 //
 Status = mSmmAccess->Close (mSmmAccess);
 ASSERT_EFI_ERROR (Status);
-- 
2.16.1.windows.1

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


Re: [edk2] [PATCH 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Fix ASSERT for success.

2018-10-29 Thread Dong, Eric
Hi Marvin,

Thanks for your contribution. I have reviewed them and pushed to trunk.
SHA numbers are: 
SHA-1: 4222e8e7e421e9c8d2c2f319a3860dd3332d6255
SHA-1: 37fba7c2762e114a280e3b361b53ded034aac7e3

One more question which just curious by me, how you find this issue? by tool or 
code review?

Thanks,
Eric

> -Original Message-
> From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> Sent: Sunday, October 28, 2018 4:51 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric ; ler...@redhat.com
> Subject: [PATCH 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Fix ASSERT for
> success.
> 
> Index is initialized to MAX_UINT16 as default failure value, which is what the
> ASSERT is supposed to test for.  The ASSERT condition however can never
> return FALSE for INT16 != int, as due to Integer Promotion[1], Index is
> converted to int, which can never result in -1.
> 
> Furthermore, Index is used as a for loop index variable inbetween its
> initialization and the ASSERT, so the value is unconditionally overwritten 
> too.
> 
> Fix the ASSERT check to compare Index to its upper boundary, which it will be
> equal to if the loop was not broken out of on success.
> 
> [1] ISO/IEC 9899:2011, 6.5.9.4
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
> index b7c3ad31e82c..89b3f2b7257f 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
> @@ -110,7 +110,6 @@ GetProtectedModeCS (
>UINTNGdtEntryCount;
>UINT16   Index;
> 
> -  Index = (UINT16) -1;
>AsmReadGdtr ();
>GdtEntryCount = (GdtrDesc.Limit + 1) / sizeof
> (IA32_SEGMENT_DESCRIPTOR);
>GdtEntry = (IA32_SEGMENT_DESCRIPTOR *) GdtrDesc.Base; @@ -122,7
> +121,7 @@ GetProtectedModeCS (
>  }
>  GdtEntry++;
>}
> -  ASSERT (Index != -1);
> +  ASSERT (Index != GdtEntryCount);
>return Index * 8;
>  }
> 
> --
> 2.19.1.windows.1

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


Re: [edk2] [PATCH 0/4] Conflict Detection for Tcp and PxeBc Driver

2018-10-29 Thread Li, Songpeng
Thanks for the review, this patch and its version 2 are both dropped.


Best,
Songpeng


-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org] 
Sent: Monday, October 29, 2018 7:40 PM
To: Li, Songpeng 
Cc: edk2-devel@lists.01.org; Ye, Ting ; Fu, Siyuan 
; Wu, Jiaxin 
Subject: Re: [edk2] [PATCH 0/4] Conflict Detection for Tcp and PxeBc Driver

Hi Songpeng,

On Mon, Oct 29, 2018 at 09:53:22AM +0800, Songpeng Li wrote:
> Please refer to the log message of each commit for more details.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1278
> Cc: Ye Ting 
> Cc: Wu Jiaxin 
> Cc: Fu Siyuan 
> Songpeng Li (4):
>   MdeModulePkg: Add Tag Protocol for PxeBc Driver Conflict Detection.
>   MdeModulePkg/UefiPxeBcDxe: Add Conflict Detection Process.
>   NetworkPkg/UefiPxeBcDxe: Add Conflict Detection Process.
>   NetworkPkg/TcpDxe: Modify the Version of Driver Binding Protocol
> 
>  MdeModulePkg/Include/Protocol/PxeBcTag.h  | 26 
>  MdeModulePkg/MdeModulePkg.dec |  5 +++
>  .../Network/UefiPxeBcDxe/PxeBcDriver.c| 19 -
>  .../Network/UefiPxeBcDxe/PxeBcImpl.h  |  3 +-
>  .../Network/UefiPxeBcDxe/UefiPxeBcDxe.inf |  1 +

Can you ensure you use the options specified in
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-23
when generating your patches?

This way we don't need to guess which files are being modified when looking at 
the summary. And it sorts the files modified by decreasing level of abstraction 
- so we (for example) see changes to structs before we see changes to how 
structs are used.

(This comment does not in itself motivate a v2.)

Best Regards,

Leif

>  NetworkPkg/TcpDxe/TcpDriver.c |  4 +-
>  NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c | 42 ++-
>  NetworkPkg/UefiPxeBcDxe/PxeBcImpl.h   |  1 +
>  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf  |  1 +
>  9 files changed, 96 insertions(+), 6 deletions(-)  create mode 100644 
> MdeModulePkg/Include/Protocol/PxeBcTag.h
>
> --
> 2.18.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v3 1/3] MdeModulePkg/UdfDxe: Check 'Component Type' within a Path Component

2018-10-29 Thread Paulo Alcantara
Hi Hao Wu,

On October 29, 2018 10:26:15 PM GMT-03:00, Hao Wu  wrote:
>REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1279
>
>According to the ECMA-167 standard (3rd Edition - June 1997), Section
>14.16.1.1, valid values are 1 to 5. All other values will be treated as
>a
>corrupted volume.
>
>This commit will add such check within function ResolveSymlink().
>
>Cc: Leif Lindholm 
>Cc: Ruiyu Ni 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Hao Wu 
>Reviewed-by: Paulo Alcantara 
>Reviewed-by: Star Zeng 
>---
> MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c | 7 +++
> 1 file changed, 7 insertions(+)
>
>diff --git a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
>b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
>index b9ebddfe62..c15741a032 100644
>--- a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
>+++ b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
>@@ -2257,6 +2257,13 @@ ResolveSymlink (
>   }
>   FileName[Index] = L'\0';
>   break;
>+default:
>+  //
>+  // Accoring to the ECMA-167 standard (3rd Edition - June 1997),
>Section

Minor typo: s/Accoring/According/

Paulo

>+  // 14.16.1.1, all other values are reserved.
>+  //
>+  Status = EFI_VOLUME_CORRUPTED;
>+  goto Error_Find_File;
> }
> 
> //

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH v2] MdeModulePkg/PiSmmIpl: Do not reset SMRAM to UC when CPU driver runs

2018-10-29 Thread Ruiyu Ni
Today's PiSmmIpl implementation initially sets SMRAM to WB to speed
up the SMM core/modules loading before SMM CPU driver runs.
When SMM CPU driver runs, PiSmmIpl resets the SMRAM to UC. It's done
in SmmIplDxeDispatchEventNotify(). COMM_BUFFER_SMM_DISPATCH_RESTART
is returned from SMM core that SMM CPU driver is just dispatched.

Since now the SMRR is widely used to control the SMRAM cache setting.
It's not needed to reset the SMRAM to UC anymore.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Jiewen Yao 
Cc: Michael Kinney 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
index f8cbe1704b..dc0d9a70b0 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
@@ -672,19 +672,6 @@ SmmIplDxeDispatchEventNotify (
   return;
 }
 
-//
-// Attempt to reset SMRAM cacheability to UC
-// Assume CPU AP is available at this time
-//
-Status = gDS->SetMemorySpaceAttributes(
-mSmramCacheBase,
-mSmramCacheSize,
-EFI_MEMORY_UC
-);
-if (EFI_ERROR (Status)) {
-  DEBUG ((DEBUG_WARN, "SMM IPL failed to reset SMRAM window to 
EFI_MEMORY_UC\n"));
-}
-
 //
 // Close all SMRAM ranges to protect SMRAM
 //
-- 
2.16.1.windows.1

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


[edk2] [PATCH v3 3/3] MdeModulePkg/UdfDxe: Memory free/use after free in ResolveSymlink()

2018-10-29 Thread Hao Wu
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1279

For function ResolveSymlink(), the below codes:

if (CompareMem ((VOID *), (VOID *)Parent,
sizeof (UDF_FILE_INFO)) != 0) {
  CleanupFileInformation ();
}

CopyMem ((VOID *), (VOID *)File, sizeof (UDF_FILE_INFO));

If the contents in 'PreviousFile' and 'File' are the same, call to
"CleanupFileInformation ();" will free the buffers in 'File'
as well. This will lead to potential memory double free/use after free
issues.

This commit will add additional check to address the above issue.

Cc: Leif Lindholm 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Paulo Alcantara 
Reviewed-by: Star Zeng 
---
 MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c 
b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
index 2227f10d07..971f562ae2 100644
--- a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
+++ b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
@@ -2144,6 +2144,8 @@ ResolveSymlink (
   UINTN   Index;
   UINT8   CompressionId;
   UDF_FILE_INFO   PreviousFile;
+  BOOLEAN NotParent;
+  BOOLEAN NotFile;
 
   ZeroMem ((VOID *)File, sizeof (UDF_FILE_INFO));
 
@@ -2298,12 +2300,18 @@ ResolveSymlink (
   goto Error_Find_File;
 }
 
-if (CompareMem ((VOID *), (VOID *)Parent,
-sizeof (UDF_FILE_INFO)) != 0) {
+NotParent = (CompareMem ((VOID *), (VOID *)Parent,
+ sizeof (UDF_FILE_INFO)) != 0);
+NotFile   = (CompareMem ((VOID *), (VOID *)File,
+ sizeof (UDF_FILE_INFO)) != 0);
+
+if (NotParent && NotFile) {
   CleanupFileInformation ();
 }
 
-CopyMem ((VOID *), (VOID *)File, sizeof (UDF_FILE_INFO));
+if (NotFile) {
+  CopyMem ((VOID *), (VOID *)File, sizeof (UDF_FILE_INFO));
+}
   }
 
   //
-- 
2.12.0.windows.1

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


[edk2] [PATCH v3 2/3] MdeModulePkg/UdfDxe: Content check for 'File' in ResolveSymlink()

2018-10-29 Thread Hao Wu
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1279

The content within 'File' is the output data for ResolveSymlink(). This
commit will add checks to ensure the content in 'File' is valid.
Otherwise, possible null pointer dereference issue will occur during the
subsequent usage of the data returned by ResolveSymlink().

Cc: Leif Lindholm 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Paulo Alcantara 
Reviewed-by: Star Zeng 
---
 MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c | 17 
+
 1 file changed, 17 insertions(+)

diff --git a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c 
b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
index c15741a032..2227f10d07 100644
--- a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
+++ b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
@@ -2145,6 +2145,8 @@ ResolveSymlink (
   UINT8   CompressionId;
   UDF_FILE_INFO   PreviousFile;
 
+  ZeroMem ((VOID *)File, sizeof (UDF_FILE_INFO));
+
   //
   // Symlink files on UDF volumes do not contain so much data other than
   // Path Components which resolves to real filenames, so it's OK to read in
@@ -2288,6 +2290,14 @@ ResolveSymlink (
   break;
 }
 
+//
+// Check the content in the file info pointed by File.
+//
+if ((File->FileEntry == NULL) || (File->FileIdentifierDesc == NULL)) {
+  Status = EFI_VOLUME_CORRUPTED;
+  goto Error_Find_File;
+}
+
 if (CompareMem ((VOID *), (VOID *)Parent,
 sizeof (UDF_FILE_INFO)) != 0) {
   CleanupFileInformation ();
@@ -2301,6 +2311,13 @@ ResolveSymlink (
   //
   FreePool (ReadFileInfo.FileData);
 
+  //
+  // Check the content in the resolved file info.
+  //
+  if ((File->FileEntry == NULL) || (File->FileIdentifierDesc == NULL)) {
+return EFI_VOLUME_CORRUPTED;
+  }
+
   return EFI_SUCCESS;
 
 Error_Find_File:
-- 
2.12.0.windows.1

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


[edk2] [PATCH v3 0/3] UdfDxe: Additional checks for ResolveSymlink()

2018-10-29 Thread Hao Wu
V3 changes:

According to Leif's recommendation, split the original patch into 3
seperate ones.

Since there is no code changes compared with the V2 of the patch, I just
preserved the 'Reviewed-by' tags by Paulo and Star.

V2 history:

Refine type C check (refer to V1 history below) to eliminate the
unnecessary CopyMem() call.

V1 history:

The commit will add 3 types of checks for function ResolveSymlink():

A. Check for the value of 'Component Type' field within a Path Component

According to the ECMA-167 standard (3rd Edition - June 1997), Section
14.16.1.1, valid values are 1 to 5. All other values will be treated as a
corrupted volume.

B. Check for the content pointed by 'File'

Since content within 'File' is the output data for ResolveSymlink().
Checks is added to ensure the content in 'File' is valid. Otherwise,
possible null pointer dereference issue will occur during the subsequent
usage of the data returned by ResolveSymlink().

C. Check for possible memory double free/use after free case

For codes:

if (CompareMem ((VOID *), (VOID *)Parent,
sizeof (UDF_FILE_INFO)) != 0) {
  CleanupFileInformation ();
}

CopyMem ((VOID *), (VOID *)File, sizeof (UDF_FILE_INFO));

If the contents in 'PreviousFile' and 'File' are the same, call to
"CleanupFileInformation ();" will free the buffers in 'File'
as well. This will lead to potential memory double free/use after free
issues.

Cc: Leif Lindholm 
Cc: Ruiyu Ni 

Hao Wu (3):
  MdeModulePkg/UdfDxe: Check 'Component Type' within a Path Component
  MdeModulePkg/UdfDxe: Content check for 'File' in ResolveSymlink()
  MdeModulePkg/UdfDxe: Memory free/use after free in ResolveSymlink()

 MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c | 38 
++--
 1 file changed, 35 insertions(+), 3 deletions(-)

-- 
2.12.0.windows.1

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


[edk2] [PATCH v3 1/3] MdeModulePkg/UdfDxe: Check 'Component Type' within a Path Component

2018-10-29 Thread Hao Wu
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1279

According to the ECMA-167 standard (3rd Edition - June 1997), Section
14.16.1.1, valid values are 1 to 5. All other values will be treated as a
corrupted volume.

This commit will add such check within function ResolveSymlink().

Cc: Leif Lindholm 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Paulo Alcantara 
Reviewed-by: Star Zeng 
---
 MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c 
b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
index b9ebddfe62..c15741a032 100644
--- a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
+++ b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
@@ -2257,6 +2257,13 @@ ResolveSymlink (
   }
   FileName[Index] = L'\0';
   break;
+default:
+  //
+  // Accoring to the ECMA-167 standard (3rd Edition - June 1997), Section
+  // 14.16.1.1, all other values are reserved.
+  //
+  Status = EFI_VOLUME_CORRUPTED;
+  goto Error_Find_File;
 }
 
 //
-- 
2.12.0.windows.1

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


Re: [edk2] [PATCH] MdeModulePkg/UdfDxe: Additional checks for ResolveSymlink()

2018-10-29 Thread Wu, Hao A
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Leif Lindholm
> Sent: Monday, October 29, 2018 7:10 PM
> To: Wu, Hao A
> Cc: Ni, Ruiyu; Paulo Alcantara; edk2-devel@lists.01.org; Zeng, Star
> Subject: Re: [edk2] [PATCH] MdeModulePkg/UdfDxe: Additional checks for
> ResolveSymlink()
> 
> Hi Hao Wu,
> 
> I have no comment about the code changes, but would it be possible to
> split this up into three separate patches? They are three separate
> changes, but as it stands, it is not _obvious_ that they do not have
> interdependencies. Splitting them up would make that immediately
> obvious. You already have the three commit messages :)

Thanks Leif,

Yes, I will send a new series to address it.

Best Regards,
Hao Wu

> 
> Best Regards,
> 
> Leif
> 
> On Fri, Oct 26, 2018 at 03:54:57PM +0800, Hao Wu wrote:
> > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1279
> >
> > The commit will add 3 types of checks for function ResolveSymlink():
> >
> > A. Check for the value of 'Component Type' field within a Path Component
> >
> > According to the ECMA-167 standard (3rd Edition - June 1997), Section
> > 14.16.1.1, valid values are 1 to 5. All other values will be treated as a
> > corrupted volume.
> >
> > B. Check for the content pointed by 'File'
> >
> > Since content within 'File' is the output data for ResolveSymlink().
> > Checks is added to ensure the content in 'File' is valid. Otherwise,
> > possible null pointer dereference issue will occur during the subsequent
> > usage of the data returned by ResolveSymlink().
> >
> > C. Check for possible memory double free/use after free case
> >
> > For codes:
> >
> > if (CompareMem ((VOID *), (VOID *)Parent,
> > sizeof (UDF_FILE_INFO)) != 0) {
> >   CleanupFileInformation ();
> > }
> >
> > CopyMem ((VOID *), (VOID *)File, sizeof (UDF_FILE_INFO));
> >
> > If the contents in 'PreviousFile' and 'File' are the same, call to
> > "CleanupFileInformation ();" will free the buffers in 'File'
> > as well. This will lead to potential memory double free/use after free
> > issues.
> >
> > Cc: Paulo Alcantara 
> > Cc: Paulo Alcantara 
> > Cc: Ruiyu Ni 
> > Cc: Star Zeng 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Hao Wu 
> > ---
> >  .../Universal/Disk/UdfDxe/FileSystemOperations.c   | 30
> --
> >  1 file changed, 28 insertions(+), 2 deletions(-)
> >
> > diff --git a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
> b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
> > index b9ebddfe62..a89e5ba9ff 100644
> > --- a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
> > +++ b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
> > @@ -2145,6 +2145,8 @@ ResolveSymlink (
> >UINT8   CompressionId;
> >UDF_FILE_INFO   PreviousFile;
> >
> > +  ZeroMem ((VOID *)File, sizeof (UDF_FILE_INFO));
> > +
> >//
> >// Symlink files on UDF volumes do not contain so much data other than
> >// Path Components which resolves to real filenames, so it's OK to read 
> > in
> > @@ -2257,6 +2259,13 @@ ResolveSymlink (
> >}
> >FileName[Index] = L'\0';
> >break;
> > +default:
> > +  //
> > +  // Accoring to the ECMA-167 standard (3rd Edition - June 1997),
> Section
> > +  // 14.16.1.1, all other values are reserved.
> > +  //
> > +  Status = EFI_VOLUME_CORRUPTED;
> > +  goto Error_Find_File;
> >  }
> >
> >  //
> > @@ -2281,8 +2290,18 @@ ResolveSymlink (
> >break;
> >  }
> >
> > -if (CompareMem ((VOID *), (VOID *)Parent,
> > -sizeof (UDF_FILE_INFO)) != 0) {
> > +//
> > +// Check the content in the file info pointed by File.
> > +//
> > +if ((File->FileEntry == NULL) || (File->FileIdentifierDesc == NULL)) {
> > +  Status = EFI_VOLUME_CORRUPTED;
> > +  goto Error_Find_File;
> > +}
> > +
> > +if ((CompareMem ((VOID *), (VOID *)Parent,
> > +sizeof (UDF_FILE_INFO)) != 0) &&
> > +(CompareMem ((VOID *), (VOID *)File,
> > +sizeof (UDF_FILE_INFO)) != 0)) {
> >CleanupFileInformation ();
> >  }
> >
> > @@ -2294,6 +2313,13 @@ ResolveSymlink (
> >//
> >FreePool (ReadFileInfo.FileData);
> >
> > +  //
> > +  // Check the content in the resolved file info.
> > +  //
> > +  if ((File->FileEntry == NULL) || (File->FileIdentifierDesc == NULL)) {
> > +return EFI_VOLUME_CORRUPTED;
> > +  }
> > +
> >return EFI_SUCCESS;
> >
> >  Error_Find_File:
> > --
> > 2.12.0.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/Core: fix an issue of potential NULL pointer access

2018-10-29 Thread Zeng, Star
Reviewed-by: Star Zeng 

-Original Message-
From: Wang, Jian J 
Sent: Monday, October 29, 2018 4:22 PM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Zeng, Star 
Subject: [PATCH] MdeModulePkg/Core: fix an issue of potential NULL pointer 
access

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1286

This issue is introduced by bb685071c2602cf786ea84c69bbebf2158194a38.

The *MemorySpaceMap assigned with NULL (line 1710) value might be accessed 
(line 1726/1730) without any sanity check. Although it won't happen in practice 
because of line 1722, we still need to add check against NULL to make static 
code analyzer happy.

1710  *MemorySpaceMap   = NULL;
  ...
1722  if (DescriptorCount == *NumberOfDescriptors) {   ...
1726Descriptor = *MemorySpaceMap;
  ...
1730BuildMemoryDescriptor (Descriptor, Entry);

Tests:
  Pass build and boot to shell.

Cc: Hao Wu 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c 
index 8bbdf7129f..a76d2db73c 100644
--- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
+++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
@@ -1719,7 +1719,7 @@ CoreGetMemorySpaceMap (
 // AllocatePool() called below has to be running outside the GCD lock.
 //
 DescriptorCount = CoreCountGcdMapEntry ();
-if (DescriptorCount == *NumberOfDescriptors) {
+if (DescriptorCount == *NumberOfDescriptors && *MemorySpaceMap != 
+ NULL) {
   //
   // Fill in the MemorySpaceMap if no memory space map change.
   //
--
2.16.2.windows.1

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


Re: [edk2] [PATCH v2] BaseTools: Fix merge in FDF parser for OptionROM override

2018-10-29 Thread Zhu, Yonghong
Thanks for the update.

Reviewed-by: Yonghong Zhu   

Best Regards,
Zhu Yonghong


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tomas 
Pilar (tpilar)
Sent: Tuesday, October 30, 2018 12:53 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH v2] BaseTools: Fix merge in FDF parser for OptionROM 
override

Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Tomas Pilar 
---
 BaseTools/Source/Python/GenFds/FdfParser.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py 
b/BaseTools/Source/Python/GenFds/FdfParser.py
index 1c9a5130bf..44cc8f63d0 100644
--- a/BaseTools/Source/Python/GenFds/FdfParser.py
+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
@@ -4396,8 +4396,8 @@ class FdfParser:
 raise Warning.ExpectedEquals(self.FileName, 
self.CurrentLineNumber)
 # Get a list of PCI IDs
 Overrides.PciDeviceId = ""
-while (self.__GetNextHexNumber()):
-Overrides.PciDeviceId = "{} 
{}".format(Overrides.PciDeviceId, self.__Token)
+while (self._GetNextHexNumber()):
+Overrides.PciDeviceId = "{} 
{}".format(Overrides.PciDeviceId, self._Token)
 if not Overrides.PciDeviceId:
 raise Warning.Expected("one or more Hex device ids", 
self.FileName, self.CurrentLineNumber)
 continue
-- 
2.17.2

___
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] UefiCpuPkg/RegisterCpuFeaturesLib: Fix GCC build failure.

2018-10-29 Thread Dong, Eric
Hi Leif,

Got it. Will follow this rule when met similar case next time, Thanks.

Thanks,
Eric

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, October 29, 2018 7:34 PM
> To: Dong, Eric 
> Cc: edk2-devel@lists.01.org; Bi, Dandan ; Gao, Liming
> 
> Subject: Re: [edk2] [Patch] UefiCpuPkg/RegisterCpuFeaturesLib: Fix GCC
> build failure.
> 
> Hi Eric,
> 
> This has already been pushed, but for future similar fixes, please add a
> commit message specifying:
> - What failed.
> - Why it failed.
> - For which targets.
> - Versions of toolchain where the failure has been observed. (This
>   does not need to be exhaustive, just mention where the failure has
>   been seen.)
> 
> Best Regards,
> 
> Leif
> 
> On Sat, Oct 27, 2018 at 05:09:21PM +0800, Eric Dong wrote:
> > Cc: Liming Gao 
> > Cc: Dandan Bi 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Eric Dong 
> > ---
> >  UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeatures.h| 2
> +-
> >  UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c |
> > 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git
> > a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeatures.h
> > b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeatures.h
> > index b5fe8fbce1..b4c8ab777e 100644
> > --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeatures.h
> > +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeatures.h
> > @@ -203,7 +203,7 @@ CPU_FEATURE_DEPENDENCE_TYPE
> DetectFeatureScope (
> >IN CPU_FEATURES_ENTRY *CpuFeature,
> >IN BOOLEANBefore,
> > -  IN CHAR8  *NextCpuFeatureMask
> > +  IN UINT8  *NextCpuFeatureMask
> >);
> >
> >  /**
> > diff --git
> > a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> > b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> > index 9a66bc49ff..394695baf2 100644
> > ---
> > a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> > +++
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib
> > +++ .c
> > @@ -125,7 +125,7 @@ CPU_FEATURE_DEPENDENCE_TYPE
> DetectFeatureScope (
> >IN CPU_FEATURES_ENTRY *CpuFeature,
> >IN BOOLEANBefore,
> > -  IN CHAR8  *NextCpuFeatureMask
> > +  IN UINT8  *NextCpuFeatureMask
> >)
> >  {
> >//
> > --
> > 2.16.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] Another Test Message - please ignore

2018-10-29 Thread Kinney, Michael D
Chris,

Thanks!  That is working as expected now.

Mike

> -Original Message-
> From: Chris Co [mailto:christopher...@microsoft.com]
> Sent: Monday, October 29, 2018 3:50 PM
> To: Kinney, Michael D ;
> edk2-devel@lists.01.org
> Subject: RE: Another Test Message - please ignore
> 
> Testing Reply-All
> 
> Chris
> 
> > -Original Message-
> > From: edk2-devel  On
> Behalf Of Kinney,
> > Michael D
> > Sent: Monday, October 29, 2018 3:44 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] Another Test Message - please ignore
> >
> > Start new test message thread.
> >
> > Mike
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> >
> https://na01.safelinks.protection.outlook.com/?url=https
> %3A%2F%2Flists.01.o
> > rg%2Fmailman%2Flistinfo%2Fedk2-
> >
> develdata=02%7C01%7Cchristopher.co%40microsoft.com%
> 7C3b7c858a6
> >
> e34427ebfd308d63df007f3%7C72f988bf86f141af91ab2d7cd011db
> 47%7C1%7C0
> >
> %7C636764498470253846sdata=D96MYFbrcqLcaZr72ukFJ6XY
> enR4z50rD
> > hGNopmHgNc%3Dreserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] Another Test Message - please ignore

2018-10-29 Thread Chris Co via edk2-devel
Testing Reply-All

Chris

> -Original Message-
> From: edk2-devel  On Behalf Of Kinney,
> Michael D
> Sent: Monday, October 29, 2018 3:44 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Another Test Message - please ignore
> 
> Start new test message thread.
> 
> Mike
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01.o
> rg%2Fmailman%2Flistinfo%2Fedk2-
> develdata=02%7C01%7Cchristopher.co%40microsoft.com%7C3b7c858a6
> e34427ebfd308d63df007f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0
> %7C636764498470253846sdata=D96MYFbrcqLcaZr72ukFJ6XYenR4z50rD
> hGNopmHgNc%3Dreserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] Another Test Message - please ignore

2018-10-29 Thread Kinney, Michael D
Start new test message thread.

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


Re: [edk2] Test message. Please ignore.

2018-10-29 Thread Kinney, Michael D
Another test with reply_goes_to_list set to "Poster".

Mike

> -Original Message-
> From: Chris Co [mailto:christopher...@microsoft.com]
> Sent: Monday, October 29, 2018 1:12 PM
> To: Kinney, Michael D ; EDK
> II Development ; Gretzinger,
> Adam R ; Jeremiah Cox
> 
> Cc: Chad Mace ; Sean Brogan
> ; Cetola, Stephano
> 
> Subject: RE: Test message. Please ignore.
> 
> Hi Mike,
> 
> This is a Reply-All.
> 
> Chris
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Monday, October 29, 2018 1:11 PM
> > To: EDK II Development ;
> Gretzinger, Adam R
> > ; Jeremiah Cox
> ;
> > Kinney, Michael D 
> > Cc: Chris Co ; Chad Mace
> > ; Sean Brogan
> ;
> > Cetola, Stephano 
> > Subject: RE: Test message. Please ignore.
> >
> > Hi Chris,
> >
> > I am trying a different configuration setting to see
> if the posters reply-to
> > address can be preserved.
> >
> > Please try both a Reply and a Reply-All to this test
> message.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Kinney, Michael D
> > > Sent: Monday, October 29, 2018 11:32 AM
> > > To: EDK II Development ;
> Gretzinger, Adam R
> > > ; Jeremiah Cox
> ;
> > > Kinney, Michael D 
> > > Cc: Chris Co ; Chad
> Mace
> > > ; Sean Brogan
> ;
> > > Cetola, Stephano 
> > > Subject: RE: Test message. Please ignore.
> > >
> > > Chris,
> > >
> > > Thanks.  That looks like what I expected.
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf
> > > > Of Chris Co via edk2- devel
> > > > Sent: Monday, October 29, 2018 11:22 AM
> > > > To: Kinney, Michael D
> ; Gretzinger, Adam
> > > > R ;
> > > edk2-
> > > > de...@lists.01.org; Jeremiah Cox
> > > 
> > > > Cc: Chris Co ; Chad
> Mace
> > > > ; Sean Brogan
> ;
> > > > Cetola, Stephano 
> > > > Subject: Re: [edk2] Test message. Please ignore.
> > > >
> > > > Hi Mike,
> > > >
> > > > Here is a Reply All to the test message.
> > > >
> > > > Chris
> > > >
> > > > > -Original Message-
> > > > > From: Kinney, Michael D
> 
> > > > > Sent: Monday, October 29, 2018 10:31 AM
> > > > > To: Chris Co ;
> > > > Gretzinger, Adam R
> > > > > ; edk2-
> > > > de...@lists.01.org; Kinney, Michael D
> > > > > ; Jeremiah Cox
> > > > 
> > > > > Cc: Sean Brogan ;
> Cetola,
> > > > Stephano
> > > > > ; Chad Mace
> > > > 
> > > > > Subject: RE: Test message. Please ignore.
> > > > >
> > > > > Hi Chris,
> > > > >
> > > > > This is a response to this test message.  The
> Reply-
> > > To
> > > > setting has been
> > > > > updated to make sure edk2-devel is always
> present.
> > > > >
> > > > > Please do a Reply All to this test message.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Mike
> > > > >
> > > > > From: Chris Co
> [mailto:christopher...@microsoft.com]
> > > > > Sent: Friday, October 26, 2018 6:09 PM
> > > > > To: Kinney, Michael D
> ;
> > > > Gretzinger, Adam R
> > > > > ; edk2-
> > > de...@lists.01.org
> > > > > Cc: Sean Brogan ;
> > > Jeremiah
> > > > Cox
> > > > > ; Cetola, Stephano
> > > > ;
> > > > > Chad Mace 
> > > > > Subject: Test message. Please ignore.
> > > > >
> > > > > Test message. Checking for DMARC bounces...
> > > > >
> > > > > Chris
> > > > ___
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https
> %3A%2F%2Flis
> > > > ts.01.org%2Fmailman%2Flistinfo%2Fedk2-
> > develdata=02%7C01%7CChris
> > > >
> >
> topher.Co%40microsoft.com%7C868cbd744373450b6b3b08d63dda
> 97d8%7C72
> > f98
> > > >
> >
> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636764406403589714
> sda
> > ta=G
> > > >
> AoQ6V1QtnZJ1DDVKRFy2kvjtPJfWyEM6Pd4KGgzzf4%3Dreserv
> ed=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] ** NOTICE ** edk2-devel mailing list configuration changes

2018-10-29 Thread Kinney, Michael D
Hi Leif,

I can put the reply_goes_to_list option back to "Poster".

In that configuration, a user that has a DMARC policy of
reject will still have their from address munged.

But I noticed that the edk2-devel mailing list is not
present when anyone does a Reply-all to an email with
a munged from address.  That implied to me that everyone
would need to check if the edk2-devel mailing has been
removed from a Reply-all and add it back manually.  This
also seems like a non-ideal configuration option.

However, the behavior I am seeing could be due to some
of my client settings.

So I will put the reply_goes_to_list option back to
"Poster".

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, October 29, 2018 2:10 PM
> To: Kinney, Michael D 
> Cc: EDK II Development ;
> Cetola, Stephano 
> Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing list
> configuration changes
> 
> Hi Mike,
> 
> I could hypothesise about which email client you may be
> using :)
> 
> But let me instead mention that the two email clients I
> have (mutt and
> gmail web interface) behave identically - neither adds
> the original
> sender to cc when the list server forces a reply-to
> header.
> 
> Regards,
> 
> Leif
> 
> On Mon, Oct 29, 2018 at 08:49:09PM +, Kinney,
> Michael D wrote:
> > Leif,
> >
> > Very strange.  When I do the same on that email, it
> > shows Paul on the To address line.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Leif Lindholm
> [mailto:leif.lindh...@linaro.org]
> > > Sent: Monday, October 29, 2018 1:40 PM
> > > To: Kinney, Michael D 
> > > Cc: EDK II Development ;
> > > Cetola, Stephano 
> > > Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing
> list
> > > configuration changes
> > >
> > > Hi Mike,
> > >
> > > When I try to "reply-to", the email from Paul A
> Lohr,
> > > sent 10 minutes
> > > after your one below, he does not show up in either
> "to"
> > > or "cc".
> > >
> > > OK, I missed the excitement during the plugfest.
> I'll go
> > > back and see
> > > what I can find there.
> > >
> > > Regards,
> > >
> > > Leif
> > >
> > > On Mon, Oct 29, 2018 at 08:23:43PM +, Kinney,
> > > Michael D wrote:
> > > > Leif,
> > > >
> > > > I have enabled a different configuration setting
> > > > that should be better.
> > > >
> > > > Please try some emails and let me know if there
> > > > are any impacts.
> > > >
> > > > The reason for these changes is the DMARC related
> > > > issue that occurred on 10-19-2018 that required a
> > > > number of users to be disabled.  The goal of these
> > > > changes is to enable those users to be re-
> activated.
> > > >
> > > > Thanks,
> > > >
> > > > Mike
> > > >
> > > > > -Original Message-
> > > > > From: Leif Lindholm
> > > [mailto:leif.lindh...@linaro.org]
> > > > > Sent: Monday, October 29, 2018 12:54 PM
> > > > > To: EDK II Development 
> > > > > Cc: Kinney, Michael D
> ;
> > > > > Cetola, Stephano 
> > > > > Subject: Re: [edk2] ** NOTICE ** edk2-devel
> mailing
> > > list
> > > > > configuration changes
> > > > >
> > > > > Hi Mike,
> > > > >
> > > > > On Mon, Oct 29, 2018 at 06:42:44PM +,
> Kinney,
> > > > > Michael D wrote:
> > > > > > Some configuration changes have been made to
> > > > > > the edk2-devel mailing list to handle posts
> from
> > > > > > a domain with a DMARC Reject/Quarantine policy
> > > > > > enabled. If this is detected then the from
> address
> > > > > > is now munged.
> > > > > >
> > > > > > One side effect of this setting is that the
> > > > > > behavior of Reply has changed.  Instead of
> being
> > > > > > a reply to the poster of the message, the
> Reply
> > > > > > address is the edk2-devel mailing list.
> > > > >
> > > > > The behaviour looks somewhat broken, since as
> far as
> > > I
> > > > > can tell,
> > > > > replies now longer include the person you're
> > > replying
> > > > > to.
> > > > > (This doesn't happen when replying specifically
> to
> > > > > _you_, because you
> > > > > cc yourself on everything).
> > > > >
> > > > > > If you wish to send a private reply to only
> the
> > > > > > poster of the message, you may have to perform
> > > > > > some manual steps.
> > > > > >
> > > > > > Please let me know if you have any concerns
> about
> > > > > > these changes or if these configuration
> changes
> > > > > > cause any other side effects.
> > > > >
> > > > > Can we make sure the person being replied to is
> at
> > > least
> > > > > on cc?
> > > > > Otherwise, we've just broken the workflow for
> anyone
> > > > > filtering on
> > > > > whether they are on "to" or "cc".
> > > > >
> > > > > Why was this change necessary?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] ** NOTICE ** edk2-devel mailing list configuration changes

2018-10-29 Thread Carsey, Jaben
I have the same behavior as Leif describes (with probably the hypothesized 
client).

When I reply, I get nothing but the mailing list in "to" (empty "cc").

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Leif Lindholm
> Sent: Monday, October 29, 2018 2:10 PM
> To: Kinney, Michael D 
> Cc: EDK II Development ; Cetola, Stephano
> 
> Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing list configuration
> changes
> 
> Hi Mike,
> 
> I could hypothesise about which email client you may be using :)
> 
> But let me instead mention that the two email clients I have (mutt and
> gmail web interface) behave identically - neither adds the original
> sender to cc when the list server forces a reply-to header.
> 
> Regards,
> 
> Leif
> 
> On Mon, Oct 29, 2018 at 08:49:09PM +, Kinney, Michael D wrote:
> > Leif,
> >
> > Very strange.  When I do the same on that email, it
> > shows Paul on the To address line.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > Sent: Monday, October 29, 2018 1:40 PM
> > > To: Kinney, Michael D 
> > > Cc: EDK II Development ;
> > > Cetola, Stephano 
> > > Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing list
> > > configuration changes
> > >
> > > Hi Mike,
> > >
> > > When I try to "reply-to", the email from Paul A Lohr,
> > > sent 10 minutes
> > > after your one below, he does not show up in either "to"
> > > or "cc".
> > >
> > > OK, I missed the excitement during the plugfest. I'll go
> > > back and see
> > > what I can find there.
> > >
> > > Regards,
> > >
> > > Leif
> > >
> > > On Mon, Oct 29, 2018 at 08:23:43PM +, Kinney,
> > > Michael D wrote:
> > > > Leif,
> > > >
> > > > I have enabled a different configuration setting
> > > > that should be better.
> > > >
> > > > Please try some emails and let me know if there
> > > > are any impacts.
> > > >
> > > > The reason for these changes is the DMARC related
> > > > issue that occurred on 10-19-2018 that required a
> > > > number of users to be disabled.  The goal of these
> > > > changes is to enable those users to be re-activated.
> > > >
> > > > Thanks,
> > > >
> > > > Mike
> > > >
> > > > > -Original Message-
> > > > > From: Leif Lindholm
> > > [mailto:leif.lindh...@linaro.org]
> > > > > Sent: Monday, October 29, 2018 12:54 PM
> > > > > To: EDK II Development 
> > > > > Cc: Kinney, Michael D ;
> > > > > Cetola, Stephano 
> > > > > Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing
> > > list
> > > > > configuration changes
> > > > >
> > > > > Hi Mike,
> > > > >
> > > > > On Mon, Oct 29, 2018 at 06:42:44PM +, Kinney,
> > > > > Michael D wrote:
> > > > > > Some configuration changes have been made to
> > > > > > the edk2-devel mailing list to handle posts from
> > > > > > a domain with a DMARC Reject/Quarantine policy
> > > > > > enabled. If this is detected then the from address
> > > > > > is now munged.
> > > > > >
> > > > > > One side effect of this setting is that the
> > > > > > behavior of Reply has changed.  Instead of being
> > > > > > a reply to the poster of the message, the Reply
> > > > > > address is the edk2-devel mailing list.
> > > > >
> > > > > The behaviour looks somewhat broken, since as far as
> > > I
> > > > > can tell,
> > > > > replies now longer include the person you're
> > > replying
> > > > > to.
> > > > > (This doesn't happen when replying specifically to
> > > > > _you_, because you
> > > > > cc yourself on everything).
> > > > >
> > > > > > If you wish to send a private reply to only the
> > > > > > poster of the message, you may have to perform
> > > > > > some manual steps.
> > > > > >
> > > > > > Please let me know if you have any concerns about
> > > > > > these changes or if these configuration changes
> > > > > > cause any other side effects.
> > > > >
> > > > > Can we make sure the person being replied to is at
> > > least
> > > > > on cc?
> > > > > Otherwise, we've just broken the workflow for anyone
> > > > > filtering on
> > > > > whether they are on "to" or "cc".
> > > > >
> > > > > Why was this change necessary?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Leif
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH v2 1/2] ShellPkg-UefiShellLib: Add a function to fully-qualify paths

2018-10-29 Thread Jim.Dailey
Add a function to return a clean, fully-qualified version of some path.

This function handles a (possibly "dirty") input path that may or may
not include a file system reference.

If it does not include a file system reference, then if the input path
does not begin with a forward or backward slash, then the input path is
relative to the current working directory of the current file system.
Otherwise, it is an absolute path within the current file system.

If it does include a file system reference, it may be a reference to the
current or some other file system.  If the file system reference is not
immediately followed by a forward or backward slash, then the input path
is relative to the current working directory of the given file system.
Otherwise, it is an absolute path within the given file system.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jim Dailey 
---
 ShellPkg/Include/Library/ShellLib.h  |  35 ++
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 124 ++-
 2 files changed, 158 insertions(+), 1 deletion(-)

diff --git a/ShellPkg/Include/Library/ShellLib.h 
b/ShellPkg/Include/Library/ShellLib.h
index 92fddc50f5..2ecc5ee006 100644
--- a/ShellPkg/Include/Library/ShellLib.h
+++ b/ShellPkg/Include/Library/ShellLib.h
@@ -2,6 +2,7 @@
   Provides interface to shell functionality for shell commands and 
applications.
 
   Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+  Copyright 2018 Dell Technologies.
   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
@@ -35,6 +36,40 @@
 extern EFI_SHELL_PARAMETERS_PROTOCOL *gEfiShellParametersProtocol;
 extern EFI_SHELL_PROTOCOL*gEfiShellProtocol;
 
+/**
+  Return a clean, fully-qualified version of an input path.  If the return 
value
+  is non-NULL the caller must free the memory when it is no longer needed.
+
+  If asserts are disabled, and if the input parameter is NULL, NULL is 
returned.
+
+  If there is not enough memory available to create the fully-qualified path or
+  a copy of the input path, NULL is returned.
+
+  If there is no working directory, a clean copy of Path is returned.
+
+  Otherwise, the current file system or working directory (as appropriate) is
+  prepended to Path and the resulting path is cleaned and returned.
+
+  NOTE: If the input path is an empty string, then the current working 
directory
+  (if it exists) is returned.  In other words, an empty input path is treated
+  exactly the same as ".".
+
+  @param[in] Path  A pointer to some file or directory path.
+
+  @retval NULL  The input path is NULL or out of memory.
+
+  @retval non-NULL  A pointer to a clean, fully-qualified version of Path.
+If there is no working directory, then a pointer to a
+clean, but not necessarily fully-qualified version of
+Path.  The caller must free this memory when it is no
+longer needed.
+**/
+CHAR16*
+EFIAPI
+FullyQualifyPath(
+  IN CONST CHAR16 *Path
+  );
+
 /**
   This function will retrieve the information about the file for the handle
   specified and store it in allocated pool memory.
diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index f04adbb63f..8467eb8953 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -2,7 +2,7 @@
   Provides interface to shell functionality for shell commands and 
applications.
 
   (C) Copyright 2016 Hewlett Packard Enterprise Development LP
-  Copyright 2016 Dell Inc.
+  Copyright 2016-2018 Dell Technologies.
   Copyright (c) 2006 - 2018, 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
@@ -36,6 +36,128 @@ EFI_HANDLEmEfiShellEnvironment2Handle;
 FILE_HANDLE_FUNCTION_MAP  FileFunctionMap;
 EFI_UNICODE_COLLATION_PROTOCOL  *mUnicodeCollationProtocol;
 
+/**
+  Return a clean, fully-qualified version of an input path.  If the return 
value
+  is non-NULL the caller must free the memory when it is no longer needed.
+
+  If asserts are disabled, and if the input parameter is NULL, NULL is 
returned.
+
+  If there is not enough memory available to create the fully-qualified path or
+  a copy of the input path, NULL is returned.
+
+  If there is no working directory, a clean copy of Path is returned.
+
+  Otherwise, the current file system or working directory (as appropriate) is
+  prepended to Path and the resulting path is cleaned and returned.
+
+  NOTE: If the input path is an empty string, then the current working 
directory
+  (if it exists) is returned.  In other words, an empty input path is 

[edk2] [PATCH v2 2/2] ShellPkg-ShellApp: Provide fully-qualified path to shell scripts

2018-10-29 Thread Jim.Dailey
Provide fully-qualified path to shell scripts

Section 3.6.2 of version 2.2 of the shell specification requires that
the first positional argument (i.e. arg 0) of a shell script resolves
to "the full path name of the script itself."

Ensure that the startup script and any scripts launched by the shell
meet this requirement.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jim Dailey 
---
 ShellPkg/Application/Shell/Shell.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Application/Shell/Shell.c 
b/ShellPkg/Application/Shell/Shell.c
index 6185b6ac80..104f4c8961 100644
--- a/ShellPkg/Application/Shell/Shell.c
+++ b/ShellPkg/Application/Shell/Shell.c
@@ -3,6 +3,7 @@
 
   Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
   (C) Copyright 2013-2014 Hewlett-Packard Development Company, L.P.
+  Copyright 2015-2018 Dell Technologies.
   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
@@ -1208,6 +1209,7 @@ DoStartupScript(
   UINTN Delay;
   EFI_INPUT_KEY Key;
   CHAR16*FileStringPath;
+  CHAR16*FullFileStringPath;
   UINTN NewSize;
 
   Key.UnicodeChar = CHAR_NULL;
@@ -1275,7 +1277,13 @@ DoStartupScript(
 
   FileStringPath = LocateStartupScript (ImagePath, FilePath);
   if (FileStringPath != NULL) {
-Status = RunScriptFile (FileStringPath, NULL, L"", 
ShellInfoObject.NewShellParametersProtocol);
+FullFileStringPath = FullyQualifyPath(FileStringPath);
+if (FullFileStringPath == NULL) {
+  Status = RunScriptFile (FileStringPath, NULL, FileStringPath, 
ShellInfoObject.NewShellParametersProtocol);
+} else {
+  Status = RunScriptFile (FullFileStringPath, NULL, FullFileStringPath, 
ShellInfoObject.NewShellParametersProtocol);
+  FreePool(FullFileStringPath);
+}
 FreePool (FileStringPath);
   } else {
 //
@@ -2429,6 +2437,7 @@ RunCommandOrFile(
   EFI_STATUSStatus;
   EFI_STATUSStartStatus;
   CHAR16*CommandWithPath;
+  CHAR16*FullCommandWithPath;
   EFI_DEVICE_PATH_PROTOCOL  *DevPath;
   SHELL_STATUS  CalleeExitStatus;
 
@@ -2474,7 +2483,13 @@ RunCommandOrFile(
   }
   switch (Type) {
 case   Script_File_Name:
-  Status = RunScriptFile (CommandWithPath, NULL, CmdLine, 
ParamProtocol);
+  FullCommandWithPath = FullyQualifyPath(CommandWithPath);
+  if (FullCommandWithPath == NULL) {
+Status = RunScriptFile (CommandWithPath, NULL, CmdLine, 
ParamProtocol);
+  } else {
+Status = RunScriptFile (FullCommandWithPath, NULL, CmdLine, 
ParamProtocol);
+FreePool(FullCommandWithPath);
+  }
   break;
 case   Efi_Application:
   //
@@ -2812,7 +2827,12 @@ RunScriptFileHandle (
   DeleteScriptFileStruct(NewScriptFile);
   return (EFI_OUT_OF_RESOURCES);
 }
-for (LoopVar = 0 ; LoopVar < 10 && LoopVar < NewScriptFile->Argc; 
LoopVar++) {
+//
+// Put the full path of the script file into Argv[0] as required by section
+// 3.6.2 of version 2.2 of the shell specification.
+//
+NewScriptFile->Argv[0] = StrnCatGrow(>Argv[0], NULL, 
NewScriptFile->ScriptName, 0);
+for (LoopVar = 1 ; LoopVar < 10 && LoopVar < NewScriptFile->Argc; 
LoopVar++) {
   ASSERT(NewScriptFile->Argv[LoopVar] == NULL);
   NewScriptFile->Argv[LoopVar] = 
StrnCatGrow(>Argv[LoopVar], NULL, 
ShellInfoObject.NewShellParametersProtocol->Argv[LoopVar], 0);
   if (NewScriptFile->Argv[LoopVar] == NULL) {
-- 
2.17.0.windows.1

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


Re: [edk2] ** NOTICE ** edk2-devel mailing list configuration changes

2018-10-29 Thread Leif Lindholm
Hi Mike,

I could hypothesise about which email client you may be using :)

But let me instead mention that the two email clients I have (mutt and
gmail web interface) behave identically - neither adds the original
sender to cc when the list server forces a reply-to header.

Regards,

Leif

On Mon, Oct 29, 2018 at 08:49:09PM +, Kinney, Michael D wrote:
> Leif,
> 
> Very strange.  When I do the same on that email, it
> shows Paul on the To address line.  
> 
> Mike
> 
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Monday, October 29, 2018 1:40 PM
> > To: Kinney, Michael D 
> > Cc: EDK II Development ;
> > Cetola, Stephano 
> > Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing list
> > configuration changes
> > 
> > Hi Mike,
> > 
> > When I try to "reply-to", the email from Paul A Lohr,
> > sent 10 minutes
> > after your one below, he does not show up in either "to"
> > or "cc".
> > 
> > OK, I missed the excitement during the plugfest. I'll go
> > back and see
> > what I can find there.
> > 
> > Regards,
> > 
> > Leif
> > 
> > On Mon, Oct 29, 2018 at 08:23:43PM +, Kinney,
> > Michael D wrote:
> > > Leif,
> > >
> > > I have enabled a different configuration setting
> > > that should be better.
> > >
> > > Please try some emails and let me know if there
> > > are any impacts.
> > >
> > > The reason for these changes is the DMARC related
> > > issue that occurred on 10-19-2018 that required a
> > > number of users to be disabled.  The goal of these
> > > changes is to enable those users to be re-activated.
> > >
> > > Thanks,
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: Leif Lindholm
> > [mailto:leif.lindh...@linaro.org]
> > > > Sent: Monday, October 29, 2018 12:54 PM
> > > > To: EDK II Development 
> > > > Cc: Kinney, Michael D ;
> > > > Cetola, Stephano 
> > > > Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing
> > list
> > > > configuration changes
> > > >
> > > > Hi Mike,
> > > >
> > > > On Mon, Oct 29, 2018 at 06:42:44PM +, Kinney,
> > > > Michael D wrote:
> > > > > Some configuration changes have been made to
> > > > > the edk2-devel mailing list to handle posts from
> > > > > a domain with a DMARC Reject/Quarantine policy
> > > > > enabled. If this is detected then the from address
> > > > > is now munged.
> > > > >
> > > > > One side effect of this setting is that the
> > > > > behavior of Reply has changed.  Instead of being
> > > > > a reply to the poster of the message, the Reply
> > > > > address is the edk2-devel mailing list.
> > > >
> > > > The behaviour looks somewhat broken, since as far as
> > I
> > > > can tell,
> > > > replies now longer include the person you're
> > replying
> > > > to.
> > > > (This doesn't happen when replying specifically to
> > > > _you_, because you
> > > > cc yourself on everything).
> > > >
> > > > > If you wish to send a private reply to only the
> > > > > poster of the message, you may have to perform
> > > > > some manual steps.
> > > > >
> > > > > Please let me know if you have any concerns about
> > > > > these changes or if these configuration changes
> > > > > cause any other side effects.
> > > >
> > > > Can we make sure the person being replied to is at
> > least
> > > > on cc?
> > > > Otherwise, we've just broken the workflow for anyone
> > > > filtering on
> > > > whether they are on "to" or "cc".
> > > >
> > > > Why was this change necessary?
> > > >
> > > > Regards,
> > > >
> > > > Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] ** NOTICE ** edk2-devel mailing list configuration changes

2018-10-29 Thread Kinney, Michael D
Leif,

Very strange.  When I do the same on that email, it
shows Paul on the To address line.  

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, October 29, 2018 1:40 PM
> To: Kinney, Michael D 
> Cc: EDK II Development ;
> Cetola, Stephano 
> Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing list
> configuration changes
> 
> Hi Mike,
> 
> When I try to "reply-to", the email from Paul A Lohr,
> sent 10 minutes
> after your one below, he does not show up in either "to"
> or "cc".
> 
> OK, I missed the excitement during the plugfest. I'll go
> back and see
> what I can find there.
> 
> Regards,
> 
> Leif
> 
> On Mon, Oct 29, 2018 at 08:23:43PM +, Kinney,
> Michael D wrote:
> > Leif,
> >
> > I have enabled a different configuration setting
> > that should be better.
> >
> > Please try some emails and let me know if there
> > are any impacts.
> >
> > The reason for these changes is the DMARC related
> > issue that occurred on 10-19-2018 that required a
> > number of users to be disabled.  The goal of these
> > changes is to enable those users to be re-activated.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Leif Lindholm
> [mailto:leif.lindh...@linaro.org]
> > > Sent: Monday, October 29, 2018 12:54 PM
> > > To: EDK II Development 
> > > Cc: Kinney, Michael D ;
> > > Cetola, Stephano 
> > > Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing
> list
> > > configuration changes
> > >
> > > Hi Mike,
> > >
> > > On Mon, Oct 29, 2018 at 06:42:44PM +, Kinney,
> > > Michael D wrote:
> > > > Some configuration changes have been made to
> > > > the edk2-devel mailing list to handle posts from
> > > > a domain with a DMARC Reject/Quarantine policy
> > > > enabled. If this is detected then the from address
> > > > is now munged.
> > > >
> > > > One side effect of this setting is that the
> > > > behavior of Reply has changed.  Instead of being
> > > > a reply to the poster of the message, the Reply
> > > > address is the edk2-devel mailing list.
> > >
> > > The behaviour looks somewhat broken, since as far as
> I
> > > can tell,
> > > replies now longer include the person you're
> replying
> > > to.
> > > (This doesn't happen when replying specifically to
> > > _you_, because you
> > > cc yourself on everything).
> > >
> > > > If you wish to send a private reply to only the
> > > > poster of the message, you may have to perform
> > > > some manual steps.
> > > >
> > > > Please let me know if you have any concerns about
> > > > these changes or if these configuration changes
> > > > cause any other side effects.
> > >
> > > Can we make sure the person being replied to is at
> least
> > > on cc?
> > > Otherwise, we've just broken the workflow for anyone
> > > filtering on
> > > whether they are on "to" or "cc".
> > >
> > > Why was this change necessary?
> > >
> > > Regards,
> > >
> > > Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] ** NOTICE ** edk2-devel mailing list configuration changes

2018-10-29 Thread Leif Lindholm
Hi Mike,

When I try to "reply-to", the email from Paul A Lohr, sent 10 minutes
after your one below, he does not show up in either "to" or "cc".

OK, I missed the excitement during the plugfest. I'll go back and see
what I can find there.

Regards,

Leif

On Mon, Oct 29, 2018 at 08:23:43PM +, Kinney, Michael D wrote:
> Leif,
> 
> I have enabled a different configuration setting 
> that should be better.
> 
> Please try some emails and let me know if there
> are any impacts.
> 
> The reason for these changes is the DMARC related
> issue that occurred on 10-19-2018 that required a
> number of users to be disabled.  The goal of these
> changes is to enable those users to be re-activated.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Monday, October 29, 2018 12:54 PM
> > To: EDK II Development 
> > Cc: Kinney, Michael D ;
> > Cetola, Stephano 
> > Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing list
> > configuration changes
> > 
> > Hi Mike,
> > 
> > On Mon, Oct 29, 2018 at 06:42:44PM +, Kinney,
> > Michael D wrote:
> > > Some configuration changes have been made to
> > > the edk2-devel mailing list to handle posts from
> > > a domain with a DMARC Reject/Quarantine policy
> > > enabled. If this is detected then the from address
> > > is now munged.
> > >
> > > One side effect of this setting is that the
> > > behavior of Reply has changed.  Instead of being
> > > a reply to the poster of the message, the Reply
> > > address is the edk2-devel mailing list.
> > 
> > The behaviour looks somewhat broken, since as far as I
> > can tell,
> > replies now longer include the person you're replying
> > to.
> > (This doesn't happen when replying specifically to
> > _you_, because you
> > cc yourself on everything).
> > 
> > > If you wish to send a private reply to only the
> > > poster of the message, you may have to perform
> > > some manual steps.
> > >
> > > Please let me know if you have any concerns about
> > > these changes or if these configuration changes
> > > cause any other side effects.
> > 
> > Can we make sure the person being replied to is at least
> > on cc?
> > Otherwise, we've just broken the workflow for anyone
> > filtering on
> > whether they are on "to" or "cc".
> > 
> > Why was this change necessary?
> > 
> > Regards,
> > 
> > Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] MdeModulePkg/PiSmmIpl: Do not reset SMRAM to UC when CPU driver runs

2018-10-29 Thread Lohr, Paul A
Hello - update on this issue:

1) SMRAM = UC in SmmIplDxeDispatchEventNotify() around line 650 can be removed, 
yes.  Code never modified anything, so there is nothing to "undo."
2) SMRAM = WB \ SMRAM = UC in SmmIplEntry() around lines 1600-1675 is still 
being considered. 

Please separate these check-ins and begin checking in #1.  We can continue the 
discussion on #2.

Paul A. Lohr – Server Firmware Enabling
512.239.9073 (cell)
512.794.5044 (work)

-Original Message-
From: Laszlo Ersek  
Sent: Tuesday, October 23, 2018 4:44 AM
To: Ni, Ruiyu ; Lohr, Paul A ; 
edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Yao, Jiewen 

Subject: Re: [edk2] [PATCH] MdeModulePkg/PiSmmIpl: Do not reset SMRAM to UC 
when CPU driver runs

On 10/23/18 11:36, Ni, Ruiyu wrote:
> On 10/23/2018 11:12 AM, Lohr, Paul A wrote:
>> Hello,
>>
>> Code to remove SMRAM = UC (line 650-ish) looks good.  I would suggest 
>> adding some debug comments in the area it was removed.  Thanks.
> 
> debug message or comments?
> I guess you'd like to have some comments to say "SMRR is enabled by 
> CPU SMM driver so no need to reset the SMRAM to UC in MTRR". Correct?

Such a comment sounds great to me, just please include: "by calling 
SmmCpuFeaturesInitializeProcessor from SmmCpuFeaturesLib".

[...]

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


Re: [edk2] ** NOTICE ** edk2-devel mailing list configuration changes

2018-10-29 Thread Kinney, Michael D
Leif,

I have enabled a different configuration setting 
that should be better.

Please try some emails and let me know if there
are any impacts.

The reason for these changes is the DMARC related
issue that occurred on 10-19-2018 that required a
number of users to be disabled.  The goal of these
changes is to enable those users to be re-activated.

Thanks,

Mike

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, October 29, 2018 12:54 PM
> To: EDK II Development 
> Cc: Kinney, Michael D ;
> Cetola, Stephano 
> Subject: Re: [edk2] ** NOTICE ** edk2-devel mailing list
> configuration changes
> 
> Hi Mike,
> 
> On Mon, Oct 29, 2018 at 06:42:44PM +, Kinney,
> Michael D wrote:
> > Some configuration changes have been made to
> > the edk2-devel mailing list to handle posts from
> > a domain with a DMARC Reject/Quarantine policy
> > enabled. If this is detected then the from address
> > is now munged.
> >
> > One side effect of this setting is that the
> > behavior of Reply has changed.  Instead of being
> > a reply to the poster of the message, the Reply
> > address is the edk2-devel mailing list.
> 
> The behaviour looks somewhat broken, since as far as I
> can tell,
> replies now longer include the person you're replying
> to.
> (This doesn't happen when replying specifically to
> _you_, because you
> cc yourself on everything).
> 
> > If you wish to send a private reply to only the
> > poster of the message, you may have to perform
> > some manual steps.
> >
> > Please let me know if you have any concerns about
> > these changes or if these configuration changes
> > cause any other side effects.
> 
> Can we make sure the person being replied to is at least
> on cc?
> Otherwise, we've just broken the workflow for anyone
> filtering on
> whether they are on "to" or "cc".
> 
> Why was this change necessary?
> 
> Regards,
> 
> Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] Test message. Please ignore.

2018-10-29 Thread Chris Co via edk2-devel
Hi Mike,

This is a Reply-All.

Chris

> -Original Message-
> From: Kinney, Michael D 
> Sent: Monday, October 29, 2018 1:11 PM
> To: EDK II Development ; Gretzinger, Adam R
> ; Jeremiah Cox ;
> Kinney, Michael D 
> Cc: Chris Co ; Chad Mace
> ; Sean Brogan ;
> Cetola, Stephano 
> Subject: RE: Test message. Please ignore.
> 
> Hi Chris,
> 
> I am trying a different configuration setting to see if the posters reply-to
> address can be preserved.
> 
> Please try both a Reply and a Reply-All to this test message.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Monday, October 29, 2018 11:32 AM
> > To: EDK II Development ; Gretzinger, Adam R
> > ; Jeremiah Cox ;
> > Kinney, Michael D 
> > Cc: Chris Co ; Chad Mace
> > ; Sean Brogan ;
> > Cetola, Stephano 
> > Subject: RE: Test message. Please ignore.
> >
> > Chris,
> >
> > Thanks.  That looks like what I expected.
> >
> > Mike
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel- boun...@lists.01.org] On Behalf
> > > Of Chris Co via edk2- devel
> > > Sent: Monday, October 29, 2018 11:22 AM
> > > To: Kinney, Michael D ; Gretzinger, Adam
> > > R ;
> > edk2-
> > > de...@lists.01.org; Jeremiah Cox
> > 
> > > Cc: Chris Co ; Chad Mace
> > > ; Sean Brogan ;
> > > Cetola, Stephano 
> > > Subject: Re: [edk2] Test message. Please ignore.
> > >
> > > Hi Mike,
> > >
> > > Here is a Reply All to the test message.
> > >
> > > Chris
> > >
> > > > -Original Message-
> > > > From: Kinney, Michael D 
> > > > Sent: Monday, October 29, 2018 10:31 AM
> > > > To: Chris Co ;
> > > Gretzinger, Adam R
> > > > ; edk2-
> > > de...@lists.01.org; Kinney, Michael D
> > > > ; Jeremiah Cox
> > > 
> > > > Cc: Sean Brogan ; Cetola,
> > > Stephano
> > > > ; Chad Mace
> > > 
> > > > Subject: RE: Test message. Please ignore.
> > > >
> > > > Hi Chris,
> > > >
> > > > This is a response to this test message.  The Reply-
> > To
> > > setting has been
> > > > updated to make sure edk2-devel is always present.
> > > >
> > > > Please do a Reply All to this test message.
> > > >
> > > > Thanks,
> > > >
> > > > Mike
> > > >
> > > > From: Chris Co [mailto:christopher...@microsoft.com]
> > > > Sent: Friday, October 26, 2018 6:09 PM
> > > > To: Kinney, Michael D ;
> > > Gretzinger, Adam R
> > > > ; edk2-
> > de...@lists.01.org
> > > > Cc: Sean Brogan ;
> > Jeremiah
> > > Cox
> > > > ; Cetola, Stephano
> > > ;
> > > > Chad Mace 
> > > > Subject: Test message. Please ignore.
> > > >
> > > > Test message. Checking for DMARC bounces...
> > > >
> > > > Chris
> > > ___
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
> > > ts.01.org%2Fmailman%2Flistinfo%2Fedk2-
> develdata=02%7C01%7CChris
> > >
> topher.Co%40microsoft.com%7C868cbd744373450b6b3b08d63dda97d8%7C72
> f98
> > >
> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636764406403589714sda
> ta=G
> > > AoQ6V1QtnZJ1DDVKRFy2kvjtPJfWyEM6Pd4KGgzzf4%3Dreserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] Test message. Please ignore.

2018-10-29 Thread Kinney, Michael D
Hi Chris,

I am trying a different configuration setting to see
if the posters reply-to address can be preserved.

Please try both a Reply and a Reply-All to
this test message.

Thanks,

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Monday, October 29, 2018 11:32 AM
> To: EDK II Development ;
> Gretzinger, Adam R ;
> Jeremiah Cox ; Kinney, Michael D
> 
> Cc: Chris Co ; Chad Mace
> ; Sean Brogan
> ; Cetola, Stephano
> 
> Subject: RE: Test message. Please ignore.
> 
> Chris,
> 
> Thanks.  That looks like what I expected.
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> > boun...@lists.01.org] On Behalf Of Chris Co via edk2-
> > devel
> > Sent: Monday, October 29, 2018 11:22 AM
> > To: Kinney, Michael D ;
> > Gretzinger, Adam R ;
> edk2-
> > de...@lists.01.org; Jeremiah Cox
> 
> > Cc: Chris Co ; Chad Mace
> > ; Sean Brogan
> > ; Cetola, Stephano
> > 
> > Subject: Re: [edk2] Test message. Please ignore.
> >
> > Hi Mike,
> >
> > Here is a Reply All to the test message.
> >
> > Chris
> >
> > > -Original Message-
> > > From: Kinney, Michael D 
> > > Sent: Monday, October 29, 2018 10:31 AM
> > > To: Chris Co ;
> > Gretzinger, Adam R
> > > ; edk2-
> > de...@lists.01.org; Kinney, Michael D
> > > ; Jeremiah Cox
> > 
> > > Cc: Sean Brogan ; Cetola,
> > Stephano
> > > ; Chad Mace
> > 
> > > Subject: RE: Test message. Please ignore.
> > >
> > > Hi Chris,
> > >
> > > This is a response to this test message.  The Reply-
> To
> > setting has been
> > > updated to make sure edk2-devel is always present.
> > >
> > > Please do a Reply All to this test message.
> > >
> > > Thanks,
> > >
> > > Mike
> > >
> > > From: Chris Co [mailto:christopher...@microsoft.com]
> > > Sent: Friday, October 26, 2018 6:09 PM
> > > To: Kinney, Michael D ;
> > Gretzinger, Adam R
> > > ; edk2-
> de...@lists.01.org
> > > Cc: Sean Brogan ;
> Jeremiah
> > Cox
> > > ; Cetola, Stephano
> > ;
> > > Chad Mace 
> > > Subject: Test message. Please ignore.
> > >
> > > Test message. Checking for DMARC bounces...
> > >
> > > Chris
> > ___
> > 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] Grub Error Marvell Board

2018-10-29 Thread Leif Lindholm
Hi Sven,

On Fri, Oct 26, 2018 at 02:08:16PM +, Sven Auhagen wrote:
> I have a Marvell Board like the MCBin with an Marvell 8040 CPU.

A custom board?
Is this using one of the platforms from edk2-platforms, or something
from Marvell's repositories?

> EDK2 works fine, a Debian installer runs just fine.
> The problem comes after the installation.
> 
> When I try to boot from the eMMC where the files were installed on
> grub seems not to find the partitions anymore:
> 
> Tianocore/EDK2 firmware version MARVELL_EFI
> Press ESCAPE for boot options XhcCheckUrbResult: STALL_ERROR! Completecode = 6
> XhcControlTransfer: error - Device Error, transfer - 2
> XHCI: Don't support multi-TT feature for Hub now. (force to disable MTT)

Well, this bit is USB related, so we can probably ignore it.

> Installed Fat filesystem on BE649F98
> Installed Fat filesystem on BE80FE98
> ...[Bds]Booting Debian
> Loading driver at 0x000B6732000 EntryPoint=0x000B6732400
> Loading driver at 0x000B6732000 EntryPoint=0x000B6732400
> error: no such partition.
> Entering rescue mode...
> grub rescue>
> grub rescue> ls
> (hd0) (hd1) (hd2) (hd3)
> grub rescue> set
> cmdpath=(hd1)/efi/debian
> prefix=(hd1,gpt2)/boot/grub
> root=hd1,gpt2
> grub rescue>
> 
> Has anyone an idea why this is happening or what could be the cause?

Does your platform build configuration enable the eMMC?
The easiest explanation would be if your EDK2 simply does not support
the eMMC. As long as the hardware description tells Linux about it,
the kernel can access it even when the firmware does not know how to
use it.

Best Regards,

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


Re: [edk2] ** NOTICE ** edk2-devel mailing list configuration changes

2018-10-29 Thread Leif Lindholm
Hi Mike,

On Mon, Oct 29, 2018 at 06:42:44PM +, Kinney, Michael D wrote:
> Some configuration changes have been made to 
> the edk2-devel mailing list to handle posts from
> a domain with a DMARC Reject/Quarantine policy
> enabled. If this is detected then the from address
> is now munged.
> 
> One side effect of this setting is that the 
> behavior of Reply has changed.  Instead of being 
> a reply to the poster of the message, the Reply
> address is the edk2-devel mailing list.

The behaviour looks somewhat broken, since as far as I can tell,
replies now longer include the person you're replying to.
(This doesn't happen when replying specifically to _you_, because you
cc yourself on everything).

> If you wish to send a private reply to only the
> poster of the message, you may have to perform
> some manual steps.
> 
> Please let me know if you have any concerns about
> these changes or if these configuration changes 
> cause any other side effects.

Can we make sure the person being replied to is at least on cc?
Otherwise, we've just broken the workflow for anyone filtering on
whether they are on "to" or "cc".

Why was this change necessary?

Regards,

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


Re: [edk2] EmmcBlockIO PassThru Out of Resources

2018-10-29 Thread Sven Auhagen
Hi,

I think this is an issue with my hardware as well. The same version from git (I 
checked it out this Saturday) works on a test board of mine with the eMMC.

I will check the hardware first and write again if I can’t resolve the problem.

Best and thank you
Sven

Sent from my iPhone

On 29. Oct 2018, at 2:12 AM, Wu, Hao A  wrote:

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Sven Auhagen
>> Sent: Sunday, October 28, 2018 9:42 PM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] EmmcBlockIO PassThru Out of Resources
>>
>> Hi,
>>
>> What could be the cause of an EmmcBlockIO Passthru command to return
>> Out of Resources after switching from BDS to OS Loader?
>> OS Loader is querying the GPT Disk partition it was loaded from but gets the
>> Out of Resources error.
>>
>> Any help is appreciated.
>
> Hi,
>
> Could you help to provide some version information (like the Git hash of the
> head commit) of the code that you observe this issue?
>
> Thanks in advance.
>
> Best Regards,
> Hao Wu
>
>>
>> Best
>> Sven
>>
>>
>> Beste Grüße/Best Regards
>>
>> Sven Auhagen
>> Dipl. Math. oec., M.Sc.
>>
>> Voleatech GmbH
>> HRB: B 754643
>> USTID: DE303643180
>> Grathwohlstr. 5
>> 72762 Reutlingen
>> Tel: +49 7121539550
>> Fax: +49 7121539551
>> E-Mail: sven.auha...@voleatech.de
>>
>> www.voleatech.de
>> Diese Information ist ausschließlich für den Adressaten bestimmt und kann
>> vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie
>> nicht der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den
>> Absender und vernichten Sie diese Mail. Anderen als dem
>> bestimmungsgemäßen Adressaten ist es untersagt, diese E-Mail zu lesen, zu
>> speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu
>> verwenden. Für den Adressaten sind die Informationen in dieser Mail nur zum
>> persönlichen Gebrauch. Eine Weiterleitung darf nur nach Rücksprache mit
>> dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. Für
>> Schäden, die dem Empfänger gleichwohl durch von uns zugesandte mit Viren
>> befallene E-Mails entstehen, schließen wir jede Haftung aus.
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

Beste Grüße/Best Regards

Sven Auhagen
Dipl. Math. oec., M.Sc.

Voleatech GmbH
HRB: B 754643
USTID: DE303643180
Grathwohlstr. 5
72762 Reutlingen
Tel: +49 7121539550
Fax: +49 7121539551
E-Mail: sven.auha...@voleatech.de

www.voleatech.de
Diese Information ist ausschließlich für den Adressaten bestimmt und kann 
vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht 
der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und 
vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es 
untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren 
Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die 
Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung 
darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle 
Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns 
zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung 
aus.

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


[edk2] D06 ACPI

2018-10-29 Thread Leif Lindholm
Hi Ming,

A while back, I forwarded to Al Stone (on cc) the issues we were
having with different versions of acpica-tools and the D06 ACPI table
generation.

He's come back with a few bugs he found in the .asl, as well as a
weird bug in iasl ... apparently only reproducible under Fedora.
Since the latter has not been fully investigated yet, I'll ignore that
until someone flags this as an issue for them.

I'm attaching a simple patch that resolves all the issues on current
master. Can you please turn this into a proper patch and send out
(giving Al a Reported-by:)?

Main gist is reformatting some of the IORT into a form the current
acpica-tools can handle, but there are also some bugfixes and closing
of comment blocks.

Once I have given feedback for v1 of your edk2-platforms series,
please rebase that onto a version that incorporates these fixes for
v2.

Best Regards,

Leif

>From 5651683495f3d36c886f97db17976c9a6eac7b47 Mon Sep 17 00:00:00 2001
From: Leif Lindholm 
Date: Mon, 29 Oct 2018 16:34:23 +
Subject: [PATCH edk2-platforms] ahs3-fixes

---
 Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl   | 32 
+++-
 Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620IortNoSmmu.asl |  2 ++
 2 files changed, 13 insertions(+), 21 deletions(-)

diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl 
b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl
index 33b5d5250b..4037ea4f1b 100644
--- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl
+++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl
@@ -53,9 +53,7 @@
 [0004]  PRI Interrupt : 
 [0004] GERR Interrupt : 
 [0004] Sync Interrupt : 
-[0001]   Proximity Domain : 01
-[0001]   Reserved : 00
-[0002]   Reserved : 
+[0001]   Proximity Domain : 0001
 [0004] DeviceID mapping index : 0002
 
 [0004] Input base : 
@@ -99,9 +97,7 @@
 [0004]  PRI Interrupt : 
 [0004] GERR Interrupt : 
 [0004] Sync Interrupt : 
-[0001]   Proximity Domain : 01
-[0001]   Reserved : 00
-[0002]   Reserved : 
+[0001]   Proximity Domain : 0001
 [0004] DeviceID mapping index : 0001
 
 [0004] Input base : 7c00
@@ -139,9 +135,7 @@
 [0004]  PRI Interrupt : 
 [0004] GERR Interrupt : 
 [0004] Sync Interrupt : 
-[0001]   Proximity Domain : 01
-[0001]   Reserved : 00
-[0002]   Reserved : 
+[0001]   Proximity Domain : 0001
 [0004] DeviceID mapping index : 0001
 
 [0004] Input base : 7400
@@ -179,9 +173,7 @@
 [0004]  PRI Interrupt : 
 [0004] GERR Interrupt : 
 [0004] Sync Interrupt : 
-[0001]   Proximity Domain : 03
-[0001]   Reserved : 00
-[0002]   Reserved : 
+[0001]   Proximity Domain : 0003
 [0004] DeviceID mapping index : 0002
 
 [0004] Input base : 8000
@@ -225,9 +217,7 @@
 [0004]  PRI Interrupt : 
 [0004] GERR Interrupt : 
 [0004] Sync Interrupt : 
-[0001]   Proximity Domain : 03
-[0001]   Reserved : 00
-[0002]   Reserved : 
+[0001]   Proximity Domain : 0003
 [0004] DeviceID mapping index : 0001
 
 [0004] Input base : BC00
@@ -265,9 +255,7 @@
 [0004]  PRI Interrupt : 
 [0004] GERR Interrupt : 
 [0004] Sync Interrupt : 
-[0001]   Proximity Domain : 03
-[0001]   Reserved : 00
-[0002]   Reserved : 
+[0001]   Proximity Domain : 0003
 [0004] DeviceID mapping index : 0001
 
 [0004] Input base : B400
@@ -290,7 +278,7 @@
 [0001]   Revision : 00
 [0004]   Reserved : 
 [0004]  Mapping Count : 000C
-[0004] Mapping Offset : 0028
+[0004] Mapping Offset : 0024
 
 [0008]  Memory Properties : [IORT Memory Access Properties]
 [0004]Cache Coherency : 0001
@@ -305,6 +293,8 @@
  Device Attribute : 0

[edk2] ** NOTICE ** edk2-devel mailing list configuration changes

2018-10-29 Thread Kinney, Michael D
Hello,

Some configuration changes have been made to 
the edk2-devel mailing list to handle posts from
a domain with a DMARC Reject/Quarantine policy
enabled. If this is detected then the from address
is now munged.

One side effect of this setting is that the 
behavior of Reply has changed.  Instead of being 
a reply to the poster of the message, the Reply
address is the edk2-devel mailing list.

If you wish to send a private reply to only the
poster of the message, you may have to perform
some manual steps.

Please let me know if you have any concerns about
these changes or if these configuration changes 
cause any other side effects.

Thanks,

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


Re: [edk2] Test message. Please ignore.

2018-10-29 Thread Kinney, Michael D
Chris,

Thanks.  That looks like what I expected.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Chris Co via edk2-
> devel
> Sent: Monday, October 29, 2018 11:22 AM
> To: Kinney, Michael D ;
> Gretzinger, Adam R ; edk2-
> de...@lists.01.org; Jeremiah Cox 
> Cc: Chris Co ; Chad Mace
> ; Sean Brogan
> ; Cetola, Stephano
> 
> Subject: Re: [edk2] Test message. Please ignore.
> 
> Hi Mike,
> 
> Here is a Reply All to the test message.
> 
> Chris
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Monday, October 29, 2018 10:31 AM
> > To: Chris Co ;
> Gretzinger, Adam R
> > ; edk2-
> de...@lists.01.org; Kinney, Michael D
> > ; Jeremiah Cox
> 
> > Cc: Sean Brogan ; Cetola,
> Stephano
> > ; Chad Mace
> 
> > Subject: RE: Test message. Please ignore.
> >
> > Hi Chris,
> >
> > This is a response to this test message.  The Reply-To
> setting has been
> > updated to make sure edk2-devel is always present.
> >
> > Please do a Reply All to this test message.
> >
> > Thanks,
> >
> > Mike
> >
> > From: Chris Co [mailto:christopher...@microsoft.com]
> > Sent: Friday, October 26, 2018 6:09 PM
> > To: Kinney, Michael D ;
> Gretzinger, Adam R
> > ; edk2-devel@lists.01.org
> > Cc: Sean Brogan ; Jeremiah
> Cox
> > ; Cetola, Stephano
> ;
> > Chad Mace 
> > Subject: Test message. Please ignore.
> >
> > Test message. Checking for DMARC bounces...
> >
> > Chris
> ___
> 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] Test message. Please ignore.

2018-10-29 Thread Chris Co via edk2-devel
Hi Mike,

Here is a Reply All to the test message.

Chris

> -Original Message-
> From: Kinney, Michael D 
> Sent: Monday, October 29, 2018 10:31 AM
> To: Chris Co ; Gretzinger, Adam R
> ; edk2-devel@lists.01.org; Kinney, Michael D
> ; Jeremiah Cox 
> Cc: Sean Brogan ; Cetola, Stephano
> ; Chad Mace 
> Subject: RE: Test message. Please ignore.
> 
> Hi Chris,
> 
> This is a response to this test message.  The Reply-To setting has been
> updated to make sure edk2-devel is always present.
> 
> Please do a Reply All to this test message.
> 
> Thanks,
> 
> Mike
> 
> From: Chris Co [mailto:christopher...@microsoft.com]
> Sent: Friday, October 26, 2018 6:09 PM
> To: Kinney, Michael D ; Gretzinger, Adam R
> ; edk2-devel@lists.01.org
> Cc: Sean Brogan ; Jeremiah Cox
> ; Cetola, Stephano ;
> Chad Mace 
> Subject: Test message. Please ignore.
> 
> Test message. Checking for DMARC bounces...
> 
> Chris
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] Test message. Please ignore.

2018-10-29 Thread Kinney, Michael D
Hi Chris,

This is a response to this test message.  The Reply-To setting
has been updated to make sure edk2-devel is always present.

Please do a Reply All to this test message.

Thanks,

Mike

From: Chris Co [mailto:christopher...@microsoft.com] 
Sent: Friday, October 26, 2018 6:09 PM
To: Kinney, Michael D ; Gretzinger, Adam R 
; edk2-devel@lists.01.org
Cc: Sean Brogan ; Jeremiah Cox 
; Cetola, Stephano ; Chad 
Mace 
Subject: Test message. Please ignore.

Test message. Checking for DMARC bounces...

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


Re: [edk2] [PATCH] BaseTools: Fix typo in FDF parser for OptionROM override

2018-10-29 Thread Tomas Pilar (tpilar)
Turns out this is a merge conflict. Respinning.

On 29/10/2018 16:40, Tomas Pilar (tpilar) wrote:
> Cc: Yonghong Zhu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Tomas Pilar 
> ---
>  BaseTools/Source/Python/GenFds/FdfParser.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py 
> b/BaseTools/Source/Python/GenFds/FdfParser.py
> index 1c9a5130bf..71cce8f61e 100644
> --- a/BaseTools/Source/Python/GenFds/FdfParser.py
> +++ b/BaseTools/Source/Python/GenFds/FdfParser.py
> @@ -4396,7 +4396,7 @@ class FdfParser:
>  raise Warning.ExpectedEquals(self.FileName, 
> self.CurrentLineNumber)
>  # Get a list of PCI IDs
>  Overrides.PciDeviceId = ""
> -while (self.__GetNextHexNumber()):
> +while (self._GetNextHexNumber()):
>  Overrides.PciDeviceId = "{} 
> {}".format(Overrides.PciDeviceId, self.__Token)
>  if not Overrides.PciDeviceId:
>  raise Warning.Expected("one or more Hex device ids", 
> self.FileName, self.CurrentLineNumber)

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


[edk2] [PATCH v2] BaseTools: Fix merge in FDF parser for OptionROM override

2018-10-29 Thread Tomas Pilar (tpilar)
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Tomas Pilar 
---
 BaseTools/Source/Python/GenFds/FdfParser.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py 
b/BaseTools/Source/Python/GenFds/FdfParser.py
index 1c9a5130bf..44cc8f63d0 100644
--- a/BaseTools/Source/Python/GenFds/FdfParser.py
+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
@@ -4396,8 +4396,8 @@ class FdfParser:
 raise Warning.ExpectedEquals(self.FileName, 
self.CurrentLineNumber)
 # Get a list of PCI IDs
 Overrides.PciDeviceId = ""
-while (self.__GetNextHexNumber()):
-Overrides.PciDeviceId = "{} 
{}".format(Overrides.PciDeviceId, self.__Token)
+while (self._GetNextHexNumber()):
+Overrides.PciDeviceId = "{} 
{}".format(Overrides.PciDeviceId, self._Token)
 if not Overrides.PciDeviceId:
 raise Warning.Expected("one or more Hex device ids", 
self.FileName, self.CurrentLineNumber)
 continue
-- 
2.17.2

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


[edk2] [PATCH] BaseTools: Fix typo in FDF parser for OptionROM override

2018-10-29 Thread Tomas Pilar (tpilar)
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Tomas Pilar 
---
 BaseTools/Source/Python/GenFds/FdfParser.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py 
b/BaseTools/Source/Python/GenFds/FdfParser.py
index 1c9a5130bf..71cce8f61e 100644
--- a/BaseTools/Source/Python/GenFds/FdfParser.py
+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
@@ -4396,7 +4396,7 @@ class FdfParser:
 raise Warning.ExpectedEquals(self.FileName, 
self.CurrentLineNumber)
 # Get a list of PCI IDs
 Overrides.PciDeviceId = ""
-while (self.__GetNextHexNumber()):
+while (self._GetNextHexNumber()):
 Overrides.PciDeviceId = "{} 
{}".format(Overrides.PciDeviceId, self.__Token)
 if not Overrides.PciDeviceId:
 raise Warning.Expected("one or more Hex device ids", 
self.FileName, self.CurrentLineNumber)
-- 
2.17.2

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


Re: [edk2] [PATCH] MdeModulePkg/Core: correct one coding style

2018-10-29 Thread Jeremiah Cox via edk2-devel
Please ignore, testing DMARC issue

-Original Message-
From: edk2-devel  On Behalf Of Bi, Dandan
Sent: Friday, October 26, 2018 7:16 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Zeng, Star 
Subject: Re: [edk2] [PATCH] MdeModulePkg/Core: correct one coding style

Reviewed-by: Bi Dandan 

Thanks,
Dandan

> -Original Message-
> From: Wang, Jian J
> Sent: Saturday, October 27, 2018 10:13 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan ; Zeng, Star 
> Subject: [PATCH] MdeModulePkg/Core: correct one coding style
> 
> REF: 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzi
> lla.tianocore.org%2Fshow_bug.cgi%3Fid%3D1284data=02%7C01%7Cjereco
> x%40microsoft.com%7Cf845cc7305144d6fa26108d63bb232cd%7C72f988bf86f141a
> f91ab2d7cd011db47%7C1%7C0%7C636762033910771752sdata=Dsl5pUhg5plef
> EERnF4LnU87wwY9XBkzz%2FIw8mlP%2FdU%3Dreserved=0
> 
> Non-Boolean comparisons should use a compare operator (==, !=, >, < 
> >=, <=)
> 
> Cc: Dandan Bi 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> index 521e0d7b2a..9f89df8d8f 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> @@ -1559,7 +1559,7 @@ PromoteGuardedFreePages (
>  }
>}
> 
> -  if (AvailablePages) {
> +  if (AvailablePages != 0) {
>  DEBUG ((DEBUG_INFO, "Promoted pages: %lX (%lx)\r\n", Start, 
> (UINT64)AvailablePages));
>  ClearGuardedMemoryBits (Start, AvailablePages);
> 
> --
> 2.19.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-develdata=02%7C01%7Cjerecox%40microsoft.com%7Cf845cc7305144d6fa26108d63bb232cd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636762033910771752sdata=c3FltaTxgnzeGkEnwF1dDBc4CGyWn19XuUjnHPrgC%2Fs%3Dreserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms v1 00/12] Fix D06 SBSA/SBBR issue and improve

2018-10-29 Thread Leif Lindholm
On Mon, Oct 29, 2018 at 11:01:19PM +0800, Ming Huang wrote:
> Hi Leif,
> 
> Yes, I generated this patchset with the same git configuration as previous 
> patchset:
> ([PATCH edk2-platforms v5 00/28] Upload for D06 platform)
> and use the same command:
> git format-patch --stat=1000 --stat-graph-width=20 --cover-letter --no-binary 
> --subject-prefix="PATCH edk2-platforms" -12 -v 1 -o v1
> 
> I check the URL below, no important different configuration found.
> Have problems with this patchset?

See below:

> Thanks,
> Ming
> 
> On 10/29/2018 7:43 PM, Leif Lindholm wrote:
> > Hi Ming,
> > 
> > On Mon, Oct 29, 2018 at 11:32:37AM +0800, Ming Huang wrote:
> >> The major features of this patchset include:
> >> 1. Modify acpi table for ACS test;
> >> 2. Enable secure boot for SBBR-SCT;
> >> 3. Other change for ACS test;
> >>
> >> For this SCT issue:
> >> RT.SetVariable - Create one Time Base Auth Variable, the expect return 
> >> status
> >> should be EFI_SUCCESS – FAILURE
> >>
> >> The resule of fail is effected by the edk2 commit(67943427).
> >> If Modify Variable.c as below, this case will pass.
> >> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> >> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> >> @@ -3188,7 +3188,7 @@ VariableServiceSetVariable (
> >>  //  Maybe it's the delete operation of common authenticated variable 
> >> at
> >>  //  user physical presence.
> >>  //
> >>  if (DataSize != AUTHINFO_SIZE) {
> >> -  return EFI_UNSUPPORTED;
> >> +  return EFI_SECURITY_VIOLATION;
> >>
> >> I supect ACS SCT compatible with UEFI 2.7 spec. We will analyze this issue
> >> continue.
> >>
> >> Code can also be found in github:
> >> https://github.com/hisilicon/OpenPlatformPkg.git
> >> branch: d06-acs-platforms
> >>
> >>
> >> Ming Huang (12):
> >>   Silicon/Hisilicon/D06: Add watchdog to GTDT
> >>   Silicon/Hisilicon/D06: Drop _CID for fwts issue
> >>   Silicon/Hisilicon/D06: Fix fwts issue in Dbg2
> >>   Silicon/Hisilicon/D06: Fix fwts issue in FADT
> >>   Hisilicon/D06: Move some functions to OemMiscLib
> >>   Silicon/Hisilicon: Modify for SBBR fwts SetTime_Func test case
> >>   Hisilicon/D0x: Fix secure boot bug in FlashFvbDxe
> >>   Hisilicon/D06: Fix SBBR-SCT AuthVar issue
> >>   Silicon/Hisilicon/D06: Reserve ECAM resource in DSDT
> >>   Silicon/Hisilicon/D06: Modify GTDT timer flag
> >>   Hisilicon/D06: Modify Gic base
> >>   Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot
> >>
> >>  Silicon/Hisilicon/HisiPkg.dec |   1 +
> >>  Silicon/Hisilicon/Hisilicon.dsc.inc   |  16 ++
> >>  Platform/Hisilicon/D03/D03.dsc|   5 +
> >>  Platform/Hisilicon/D05/D05.dsc|   5 +
> >>  Platform/Hisilicon/D06/D06.dsc|   9 +-
> >>  .../Drivers/FlashFvbDxe/FlashFvbDxe.inf   |   2 +
> >>  .../M41T83RealTimeClockLib.inf|   3 +-
> >>  .../Hi1620/Hi1620AcpiTables/Hi1620Platform.h  |   2 +-
> >>  .../Hisilicon/Include/Library/OemMiscLib.h|   9 +
> >>  .../M41T83RealTimeClock.h |   8 +-
> >>  .../D06/Library/OemMiscLibD06/OemMiscLibD06.c |  82 ++
> >>  .../Drivers/FlashFvbDxe/FlashFvbDxe.c |  14 +-
> >>  .../M41T83RealTimeClockLib.c  | 263 --
> >>  .../Hi1620/Hi1620AcpiTables/Dsdt/Com.asl  |   1 -
> >>  .../Hi1620AcpiTables/Dsdt/Hi1620Mbig.asl  |  48 
> >>  .../Hi1620AcpiTables/Dsdt/Hi1620Pci.asl   |  36 ++-
> >>  .../Hi1620/Hi1620AcpiTables/Fadt.aslc |   2 +-
> >>  .../Hi1620/Hi1620AcpiTables/Gtdt.aslc |  35 +--
> >>  .../Hi1620/Hi1620AcpiTables/Hi1620Dbg2.aslc   |   4 +-
> >>  .../Hi1620/Hi1620AcpiTables/Hi1620Iort.asl|  18 +-
> >>  .../Hi1620/Hi1620AcpiTables/Hi1620Srat.aslc   | 194 ++---
> >>  .../Hi1620/Hi1620AcpiTables/MadtHi1620.aslc   |   2 +-

These ... suggest --stat=1000 was not used. Can you verify please?

Regards,

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


Re: [edk2] [PATCH edk2-platforms v1 00/12] Fix D06 SBSA/SBBR issue and improve

2018-10-29 Thread Ming Huang
Hi Leif,

Yes, I generated this patchset with the same git configuration as previous 
patchset:
([PATCH edk2-platforms v5 00/28] Upload for D06 platform)
and use the same command:
git format-patch --stat=1000 --stat-graph-width=20 --cover-letter --no-binary 
--subject-prefix="PATCH edk2-platforms" -12 -v 1 -o v1

I check the URL below, no important different configuration found.
Have problems with this patchset?

Thanks,
Ming

On 10/29/2018 7:43 PM, Leif Lindholm wrote:
> Hi Ming,
> 
> On Mon, Oct 29, 2018 at 11:32:37AM +0800, Ming Huang wrote:
>> The major features of this patchset include:
>> 1. Modify acpi table for ACS test;
>> 2. Enable secure boot for SBBR-SCT;
>> 3. Other change for ACS test;
>>
>> For this SCT issue:
>> RT.SetVariable - Create one Time Base Auth Variable, the expect return status
>> should be EFI_SUCCESS – FAILURE
>>
>> The resule of fail is effected by the edk2 commit(67943427).
>> If Modify Variable.c as below, this case will pass.
>> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
>> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
>> @@ -3188,7 +3188,7 @@ VariableServiceSetVariable (
>>  //  Maybe it's the delete operation of common authenticated variable at
>>  //  user physical presence.
>>  //
>>  if (DataSize != AUTHINFO_SIZE) {
>> -  return EFI_UNSUPPORTED;
>> +  return EFI_SECURITY_VIOLATION;
>>
>> I supect ACS SCT compatible with UEFI 2.7 spec. We will analyze this issue
>> continue.
>>
>> Code can also be found in github:
>> https://github.com/hisilicon/OpenPlatformPkg.git
>> branch: d06-acs-platforms
>>
>>
>> Ming Huang (12):
>>   Silicon/Hisilicon/D06: Add watchdog to GTDT
>>   Silicon/Hisilicon/D06: Drop _CID for fwts issue
>>   Silicon/Hisilicon/D06: Fix fwts issue in Dbg2
>>   Silicon/Hisilicon/D06: Fix fwts issue in FADT
>>   Hisilicon/D06: Move some functions to OemMiscLib
>>   Silicon/Hisilicon: Modify for SBBR fwts SetTime_Func test case
>>   Hisilicon/D0x: Fix secure boot bug in FlashFvbDxe
>>   Hisilicon/D06: Fix SBBR-SCT AuthVar issue
>>   Silicon/Hisilicon/D06: Reserve ECAM resource in DSDT
>>   Silicon/Hisilicon/D06: Modify GTDT timer flag
>>   Hisilicon/D06: Modify Gic base
>>   Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot
>>
>>  Silicon/Hisilicon/HisiPkg.dec |   1 +
>>  Silicon/Hisilicon/Hisilicon.dsc.inc   |  16 ++
>>  Platform/Hisilicon/D03/D03.dsc|   5 +
>>  Platform/Hisilicon/D05/D05.dsc|   5 +
>>  Platform/Hisilicon/D06/D06.dsc|   9 +-
>>  .../Drivers/FlashFvbDxe/FlashFvbDxe.inf   |   2 +
>>  .../M41T83RealTimeClockLib.inf|   3 +-
>>  .../Hi1620/Hi1620AcpiTables/Hi1620Platform.h  |   2 +-
>>  .../Hisilicon/Include/Library/OemMiscLib.h|   9 +
>>  .../M41T83RealTimeClock.h |   8 +-
>>  .../D06/Library/OemMiscLibD06/OemMiscLibD06.c |  82 ++
>>  .../Drivers/FlashFvbDxe/FlashFvbDxe.c |  14 +-
>>  .../M41T83RealTimeClockLib.c  | 263 --
>>  .../Hi1620/Hi1620AcpiTables/Dsdt/Com.asl  |   1 -
>>  .../Hi1620AcpiTables/Dsdt/Hi1620Mbig.asl  |  48 
>>  .../Hi1620AcpiTables/Dsdt/Hi1620Pci.asl   |  36 ++-
>>  .../Hi1620/Hi1620AcpiTables/Fadt.aslc |   2 +-
>>  .../Hi1620/Hi1620AcpiTables/Gtdt.aslc |  35 +--
>>  .../Hi1620/Hi1620AcpiTables/Hi1620Dbg2.aslc   |   4 +-
>>  .../Hi1620/Hi1620AcpiTables/Hi1620Iort.asl|  18 +-
>>  .../Hi1620/Hi1620AcpiTables/Hi1620Srat.aslc   | 194 ++---
>>  .../Hi1620/Hi1620AcpiTables/MadtHi1620.aslc   |   2 +-
> 
> Can you ensure you use the options specified in
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-23
> when generating your patches?
> 
> This way we don't need to guess which files are being modified when
> looking at the summary.
> 
> Regards,
> 
> Leif
> 
>>  22 files changed, 475 insertions(+), 284 deletions(-)
>>
>> -- 
>> 2.18.0
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [edk2-InfSpecification][PATCH v2] Amend the OptionROM specification to allow multiple PCI_DEVICE_IDs

2018-10-29 Thread Zhu, Yonghong
Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tomas 
Pilar (tpilar)
Sent: Monday, October 29, 2018 6:48 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [edk2-InfSpecification][PATCH v2] Amend the OptionROM 
specification to allow multiple PCI_DEVICE_IDs

The BaseTools have been updated to allow multiple PCI_DEVICE_IDs following the 
Device List introduced in the PCI Spec rev 3.0. This change documents the 
syntax.

Signed-off-by: Tomas Pilar 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 2_inf_overview/24_[defines]_section.md   | 2 +-
 3_edk_ii_inf_file_format/34_[defines]_section.md | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/2_inf_overview/24_[defines]_section.md 
b/2_inf_overview/24_[defines]_section.md
index 0afdfed..8e5706c 100644
--- a/2_inf_overview/24_[defines]_section.md
+++ b/2_inf_overview/24_[defines]_section.md
@@ -128,7 +128,7 @@ dispatch instance.
 |`CONSTRUCTOR`   |Not required - Library Only  
|CName   | This only applies to components 
that are libraries. It is required for EDK II libraries if the module's INF 
contains a Constructor element. This value is used to call the specified 
function before calling into the library itself.

  |
 |`DESTRUCTOR`|Not required - Library Only  
|CName   | This only applies to components 
that are libraries. This value is used to call the specified function before 
calling into the library itself.


  |
 |`SHADOW`|Not required - SEC, PEIM and PEI_CORE Driver 
modules only|TRUE  FALSE   | This boolean operator is 
used by `SEC`, `PEI_CORE` and `PEIM` modules to indicate if the module was 
coded to use `REGISTER_FOR_SHADOW`. If the value is TRUE, the .reloc section of 
the PE32 image is not removed, otherwise, the .reloc section is stripped to 
conserve space in the final binary images. The default value is FALSE.  
   |
-|`PCI_DEVICE_ID` |Not required - Required for UEFI PCI Option ROMs 
|UINT16 Value| The PCI Device Id for this 
device  



|
+|`PCI_DEVICE_ID` |Not required - Required for UEFI PCI Option ROMs 
|List of UINT16 Values   | The list of PCI Device Ids for 
this device 



|
 |`PCI_VENDOR_ID` |Not required - Required for UEFI PCI Option ROMs 
|UINT16 Value| The PCI Vendor Id for this 
device  



|
 |`PCI_CLASS_CODE`|Not required - Required for UEFI PCI Option ROMs 
|UINT8 Value | The PCI Class Code for this 
device  



   |
 |`PCI_REVISION`  |Not required - Required for UEFI PCI Option ROMs 
|UINT8 Value | The PCI revision for this device 


 

Re: [edk2] [edk2-FdfSpecification][PATCH v2] Amend the OptionROM definition to allow multiple PCI_DEVICE_IDs

2018-10-29 Thread Zhu, Yonghong
Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tomas 
Pilar (tpilar)
Sent: Monday, October 29, 2018 6:48 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [edk2-FdfSpecification][PATCH v2] Amend the OptionROM 
definition to allow multiple PCI_DEVICE_IDs

The BaseTools are updated to allow multiple PCI_DEVICE_ID fields following the 
Device List introduced in the PCI Spec rev 3.0. This commit documents the 
amended syntax.

Signed-off-by: Tomas Pilar 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 3_edk_ii_fdf_file_format/311_pci_optionrom_section.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/3_edk_ii_fdf_file_format/311_pci_optionrom_section.md 
b/3_edk_ii_fdf_file_format/311_pci_optionrom_section.md
index 08f50e7..8267fbb 100644
--- a/3_edk_ii_fdf_file_format/311_pci_optionrom_section.md
+++ b/3_edk_ii_fdf_file_format/311_pci_optionrom_section.md
@@ -58,7 +58,7 @@ Conditional statements may be used anywhere within this 
section.
 ::=  "{" 
[ "PCI_VENDOR_ID"   ]
[ "PCI_CLASS_CODE"   ]
-   [ "PCI_DEVICE_ID"   ]
+   [ "PCI_DEVICE_ID"   [ 
+ ]* ]
[ "PCI_REVISION"   ]
[ "PCI_COMPRESS"   ]
 "}" 
@@ -108,6 +108,7 @@ for the .efi extension in the ENBF above.
 [OptionRom.AtapiPassThru]
   INF USE = IA32 OptionRomPkg/AtapiPassThruDxe/AtapiPassThruDxe.inf {
 PCI_REVISION = 0x0020
+PCI_DEVICE_ID = 0x0A03 0x0B03
   }
   INF USE = EBC OptionRomPkg/AtapiPassThruDxe/AtapiPassThruDxe.inf
 ```
--
2.17.2

___
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 edk2-platforms v1 00/12] Fix D06 SBSA/SBBR issue and improve

2018-10-29 Thread Leif Lindholm
Hi Ming,

On Mon, Oct 29, 2018 at 11:32:37AM +0800, Ming Huang wrote:
> The major features of this patchset include:
> 1. Modify acpi table for ACS test;
> 2. Enable secure boot for SBBR-SCT;
> 3. Other change for ACS test;
> 
> For this SCT issue:
> RT.SetVariable - Create one Time Base Auth Variable, the expect return status
> should be EFI_SUCCESS – FAILURE
> 
> The resule of fail is effected by the edk2 commit(67943427).
> If Modify Variable.c as below, this case will pass.
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -3188,7 +3188,7 @@ VariableServiceSetVariable (
>  //  Maybe it's the delete operation of common authenticated variable at
>  //  user physical presence.
>  //
>  if (DataSize != AUTHINFO_SIZE) {
> -  return EFI_UNSUPPORTED;
> +  return EFI_SECURITY_VIOLATION;
> 
> I supect ACS SCT compatible with UEFI 2.7 spec. We will analyze this issue
> continue.
> 
> Code can also be found in github:
> https://github.com/hisilicon/OpenPlatformPkg.git
> branch: d06-acs-platforms
> 
> 
> Ming Huang (12):
>   Silicon/Hisilicon/D06: Add watchdog to GTDT
>   Silicon/Hisilicon/D06: Drop _CID for fwts issue
>   Silicon/Hisilicon/D06: Fix fwts issue in Dbg2
>   Silicon/Hisilicon/D06: Fix fwts issue in FADT
>   Hisilicon/D06: Move some functions to OemMiscLib
>   Silicon/Hisilicon: Modify for SBBR fwts SetTime_Func test case
>   Hisilicon/D0x: Fix secure boot bug in FlashFvbDxe
>   Hisilicon/D06: Fix SBBR-SCT AuthVar issue
>   Silicon/Hisilicon/D06: Reserve ECAM resource in DSDT
>   Silicon/Hisilicon/D06: Modify GTDT timer flag
>   Hisilicon/D06: Modify Gic base
>   Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot
> 
>  Silicon/Hisilicon/HisiPkg.dec |   1 +
>  Silicon/Hisilicon/Hisilicon.dsc.inc   |  16 ++
>  Platform/Hisilicon/D03/D03.dsc|   5 +
>  Platform/Hisilicon/D05/D05.dsc|   5 +
>  Platform/Hisilicon/D06/D06.dsc|   9 +-
>  .../Drivers/FlashFvbDxe/FlashFvbDxe.inf   |   2 +
>  .../M41T83RealTimeClockLib.inf|   3 +-
>  .../Hi1620/Hi1620AcpiTables/Hi1620Platform.h  |   2 +-
>  .../Hisilicon/Include/Library/OemMiscLib.h|   9 +
>  .../M41T83RealTimeClock.h |   8 +-
>  .../D06/Library/OemMiscLibD06/OemMiscLibD06.c |  82 ++
>  .../Drivers/FlashFvbDxe/FlashFvbDxe.c |  14 +-
>  .../M41T83RealTimeClockLib.c  | 263 --
>  .../Hi1620/Hi1620AcpiTables/Dsdt/Com.asl  |   1 -
>  .../Hi1620AcpiTables/Dsdt/Hi1620Mbig.asl  |  48 
>  .../Hi1620AcpiTables/Dsdt/Hi1620Pci.asl   |  36 ++-
>  .../Hi1620/Hi1620AcpiTables/Fadt.aslc |   2 +-
>  .../Hi1620/Hi1620AcpiTables/Gtdt.aslc |  35 +--
>  .../Hi1620/Hi1620AcpiTables/Hi1620Dbg2.aslc   |   4 +-
>  .../Hi1620/Hi1620AcpiTables/Hi1620Iort.asl|  18 +-
>  .../Hi1620/Hi1620AcpiTables/Hi1620Srat.aslc   | 194 ++---
>  .../Hi1620/Hi1620AcpiTables/MadtHi1620.aslc   |   2 +-

Can you ensure you use the options specified in
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-23
when generating your patches?

This way we don't need to guess which files are being modified when
looking at the summary.

Regards,

Leif

>  22 files changed, 475 insertions(+), 284 deletions(-)
> 
> -- 
> 2.18.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 0/4] Conflict Detection for Tcp and PxeBc Driver

2018-10-29 Thread Leif Lindholm
Hi Songpeng,

On Mon, Oct 29, 2018 at 09:53:22AM +0800, Songpeng Li wrote:
> Please refer to the log message of each commit for more details.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1278
> Cc: Ye Ting 
> Cc: Wu Jiaxin 
> Cc: Fu Siyuan 
> Songpeng Li (4):
>   MdeModulePkg: Add Tag Protocol for PxeBc Driver Conflict Detection.
>   MdeModulePkg/UefiPxeBcDxe: Add Conflict Detection Process.
>   NetworkPkg/UefiPxeBcDxe: Add Conflict Detection Process.
>   NetworkPkg/TcpDxe: Modify the Version of Driver Binding Protocol
> 
>  MdeModulePkg/Include/Protocol/PxeBcTag.h  | 26 
>  MdeModulePkg/MdeModulePkg.dec |  5 +++
>  .../Network/UefiPxeBcDxe/PxeBcDriver.c| 19 -
>  .../Network/UefiPxeBcDxe/PxeBcImpl.h  |  3 +-
>  .../Network/UefiPxeBcDxe/UefiPxeBcDxe.inf |  1 +

Can you ensure you use the options specified in
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-23
when generating your patches?

This way we don't need to guess which files are being modified when
looking at the summary. And it sorts the files modified by decreasing
level of abstraction - so we (for example) see changes to structs
before we see changes to how structs are used.

(This comment does not in itself motivate a v2.)

Best Regards,

Leif

>  NetworkPkg/TcpDxe/TcpDriver.c |  4 +-
>  NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c | 42 ++-
>  NetworkPkg/UefiPxeBcDxe/PxeBcImpl.h   |  1 +
>  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf  |  1 +
>  9 files changed, 96 insertions(+), 6 deletions(-)
>  create mode 100644 MdeModulePkg/Include/Protocol/PxeBcTag.h
>
> -- 
> 2.18.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch] UefiCpuPkg/RegisterCpuFeaturesLib: Fix GCC build failure.

2018-10-29 Thread Leif Lindholm
Hi Eric,

This has already been pushed, but for future similar fixes, please add
a commit message specifying:
- What failed.
- Why it failed.
- For which targets.
- Versions of toolchain where the failure has been observed. (This
  does not need to be exhaustive, just mention where the failure has
  been seen.)

Best Regards,

Leif

On Sat, Oct 27, 2018 at 05:09:21PM +0800, Eric Dong wrote:
> Cc: Liming Gao 
> Cc: Dandan Bi 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeatures.h| 2 +-
>  UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeatures.h 
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeatures.h
> index b5fe8fbce1..b4c8ab777e 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeatures.h
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeatures.h
> @@ -203,7 +203,7 @@ CPU_FEATURE_DEPENDENCE_TYPE
>  DetectFeatureScope (
>IN CPU_FEATURES_ENTRY *CpuFeature,
>IN BOOLEANBefore,
> -  IN CHAR8  *NextCpuFeatureMask
> +  IN UINT8  *NextCpuFeatureMask
>);
>  
>  /**
> diff --git 
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c 
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> index 9a66bc49ff..394695baf2 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> @@ -125,7 +125,7 @@ CPU_FEATURE_DEPENDENCE_TYPE
>  DetectFeatureScope (
>IN CPU_FEATURES_ENTRY *CpuFeature,
>IN BOOLEANBefore,
> -  IN CHAR8  *NextCpuFeatureMask
> +  IN UINT8  *NextCpuFeatureMask
>)
>  {
>//
> -- 
> 2.16.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] MdeModulePkg/UdfDxe: Additional checks for ResolveSymlink()

2018-10-29 Thread Leif Lindholm
Hi Hao Wu,

I have no comment about the code changes, but would it be possible to
split this up into three separate patches? They are three separate
changes, but as it stands, it is not _obvious_ that they do not have
interdependencies. Splitting them up would make that immediately
obvious. You already have the three commit messages :)

Best Regards,

Leif

On Fri, Oct 26, 2018 at 03:54:57PM +0800, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1279
> 
> The commit will add 3 types of checks for function ResolveSymlink():
> 
> A. Check for the value of 'Component Type' field within a Path Component
> 
> According to the ECMA-167 standard (3rd Edition - June 1997), Section
> 14.16.1.1, valid values are 1 to 5. All other values will be treated as a
> corrupted volume.
> 
> B. Check for the content pointed by 'File'
> 
> Since content within 'File' is the output data for ResolveSymlink().
> Checks is added to ensure the content in 'File' is valid. Otherwise,
> possible null pointer dereference issue will occur during the subsequent
> usage of the data returned by ResolveSymlink().
> 
> C. Check for possible memory double free/use after free case
> 
> For codes:
> 
> if (CompareMem ((VOID *), (VOID *)Parent,
> sizeof (UDF_FILE_INFO)) != 0) {
>   CleanupFileInformation ();
> }
> 
> CopyMem ((VOID *), (VOID *)File, sizeof (UDF_FILE_INFO));
> 
> If the contents in 'PreviousFile' and 'File' are the same, call to
> "CleanupFileInformation ();" will free the buffers in 'File'
> as well. This will lead to potential memory double free/use after free
> issues.
> 
> Cc: Paulo Alcantara 
> Cc: Paulo Alcantara 
> Cc: Ruiyu Ni 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  .../Universal/Disk/UdfDxe/FileSystemOperations.c   | 30 
> --
>  1 file changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c 
> b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
> index b9ebddfe62..a89e5ba9ff 100644
> --- a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
> +++ b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
> @@ -2145,6 +2145,8 @@ ResolveSymlink (
>UINT8   CompressionId;
>UDF_FILE_INFO   PreviousFile;
>  
> +  ZeroMem ((VOID *)File, sizeof (UDF_FILE_INFO));
> +
>//
>// Symlink files on UDF volumes do not contain so much data other than
>// Path Components which resolves to real filenames, so it's OK to read in
> @@ -2257,6 +2259,13 @@ ResolveSymlink (
>}
>FileName[Index] = L'\0';
>break;
> +default:
> +  //
> +  // Accoring to the ECMA-167 standard (3rd Edition - June 1997), Section
> +  // 14.16.1.1, all other values are reserved.
> +  //
> +  Status = EFI_VOLUME_CORRUPTED;
> +  goto Error_Find_File;
>  }
>  
>  //
> @@ -2281,8 +2290,18 @@ ResolveSymlink (
>break;
>  }
>  
> -if (CompareMem ((VOID *), (VOID *)Parent,
> -sizeof (UDF_FILE_INFO)) != 0) {
> +//
> +// Check the content in the file info pointed by File.
> +//
> +if ((File->FileEntry == NULL) || (File->FileIdentifierDesc == NULL)) {
> +  Status = EFI_VOLUME_CORRUPTED;
> +  goto Error_Find_File;
> +}
> +
> +if ((CompareMem ((VOID *), (VOID *)Parent,
> +sizeof (UDF_FILE_INFO)) != 0) &&
> +(CompareMem ((VOID *), (VOID *)File,
> +sizeof (UDF_FILE_INFO)) != 0)) {
>CleanupFileInformation ();
>  }
>  
> @@ -2294,6 +2313,13 @@ ResolveSymlink (
>//
>FreePool (ReadFileInfo.FileData);
>  
> +  //
> +  // Check the content in the resolved file info.
> +  //
> +  if ((File->FileEntry == NULL) || (File->FileIdentifierDesc == NULL)) {
> +return EFI_VOLUME_CORRUPTED;
> +  }
> +
>return EFI_SUCCESS;
>  
>  Error_Find_File:
> -- 
> 2.12.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [edk2-InfSpecification][PATCH v2] Amend the OptionROM specification to allow multiple PCI_DEVICE_IDs

2018-10-29 Thread Tomas Pilar (tpilar)
The BaseTools have been updated to allow multiple PCI_DEVICE_IDs following
the Device List introduced in the PCI Spec rev 3.0. This change documents
the syntax.

Signed-off-by: Tomas Pilar 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 2_inf_overview/24_[defines]_section.md   | 2 +-
 3_edk_ii_inf_file_format/34_[defines]_section.md | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/2_inf_overview/24_[defines]_section.md 
b/2_inf_overview/24_[defines]_section.md
index 0afdfed..8e5706c 100644
--- a/2_inf_overview/24_[defines]_section.md
+++ b/2_inf_overview/24_[defines]_section.md
@@ -128,7 +128,7 @@ dispatch instance.
 |`CONSTRUCTOR`   |Not required - Library Only  
|CName   | This only applies to components 
that are libraries. It is required for EDK II libraries if the module's INF 
contains a Constructor element. This value is used to call the specified 
function before calling into the library itself.

  |
 |`DESTRUCTOR`|Not required - Library Only  
|CName   | This only applies to components 
that are libraries. This value is used to call the specified function before 
calling into the library itself.


  |
 |`SHADOW`|Not required - SEC, PEIM and PEI_CORE Driver 
modules only|TRUE  FALSE   | This boolean operator is 
used by `SEC`, `PEI_CORE` and `PEIM` modules to indicate if the module was 
coded to use `REGISTER_FOR_SHADOW`. If the value is TRUE, the .reloc section of 
the PE32 image is not removed, otherwise, the .reloc section is stripped to 
conserve space in the final binary images. The default value is FALSE.  
   |
-|`PCI_DEVICE_ID` |Not required - Required for UEFI PCI Option ROMs 
|UINT16 Value| The PCI Device Id for this 
device  



|
+|`PCI_DEVICE_ID` |Not required - Required for UEFI PCI Option ROMs 
|List of UINT16 Values   | The list of PCI Device Ids for 
this device 



|
 |`PCI_VENDOR_ID` |Not required - Required for UEFI PCI Option ROMs 
|UINT16 Value| The PCI Vendor Id for this 
device  



|
 |`PCI_CLASS_CODE`|Not required - Required for UEFI PCI Option ROMs 
|UINT8 Value | The PCI Class Code for this 
device  



   |
 |`PCI_REVISION`  |Not required - Required for UEFI PCI Option ROMs 
|UINT8 Value | The PCI revision for this device 




  |
diff --git a/3_edk_ii_inf_file_format/34_[defines]_section.md 
b/3_edk_ii_inf_file_format/34_[defines]_section.md
index f512ff9..394db53 100644
--- a/3_edk_ii_inf_file_format/34_[defines]_section.md
+++ 

[edk2] [edk2-FdfSpecification][PATCH v2] Amend the OptionROM definition to allow multiple PCI_DEVICE_IDs

2018-10-29 Thread Tomas Pilar (tpilar)
The BaseTools are updated to allow multiple PCI_DEVICE_ID fields following
the Device List introduced in the PCI Spec rev 3.0. This commit documents the
amended syntax.

Signed-off-by: Tomas Pilar 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 3_edk_ii_fdf_file_format/311_pci_optionrom_section.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/3_edk_ii_fdf_file_format/311_pci_optionrom_section.md 
b/3_edk_ii_fdf_file_format/311_pci_optionrom_section.md
index 08f50e7..8267fbb 100644
--- a/3_edk_ii_fdf_file_format/311_pci_optionrom_section.md
+++ b/3_edk_ii_fdf_file_format/311_pci_optionrom_section.md
@@ -58,7 +58,7 @@ Conditional statements may be used anywhere within this 
section.
 ::=  "{" 
[ "PCI_VENDOR_ID"   ]
[ "PCI_CLASS_CODE"   ]
-   [ "PCI_DEVICE_ID"   ]
+   [ "PCI_DEVICE_ID"   [ ]* ]
[ "PCI_REVISION"   ]
[ "PCI_COMPRESS"   ]
 "}" 
@@ -108,6 +108,7 @@ for the .efi extension in the ENBF above.
 [OptionRom.AtapiPassThru]
   INF USE = IA32 OptionRomPkg/AtapiPassThruDxe/AtapiPassThruDxe.inf {
 PCI_REVISION = 0x0020
+PCI_DEVICE_ID = 0x0A03 0x0B03
   }
   INF USE = EBC OptionRomPkg/AtapiPassThruDxe/AtapiPassThruDxe.inf
 ```
-- 
2.17.2

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


Re: [edk2] [PATCH] MdeModulePkg/Core: fix an issue of potential NULL pointer access

2018-10-29 Thread Wu, Hao A
> -Original Message-
> From: Wang, Jian J
> Sent: Monday, October 29, 2018 4:22 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; Zeng, Star
> Subject: [PATCH] MdeModulePkg/Core: fix an issue of potential NULL
> pointer access
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1286
> 
> This issue is introduced by bb685071c2602cf786ea84c69bbebf2158194a38.
> 
> The *MemorySpaceMap assigned with NULL (line 1710) value might be
> accessed (line 1726/1730) without any sanity check. Although it won't
> happen in practice because of line 1722, we still need to add check
> against NULL to make static code analyzer happy.
> 
> 1710  *MemorySpaceMap   = NULL;
>   ...
> 1722  if (DescriptorCount == *NumberOfDescriptors) {
>   ...
> 1726Descriptor = *MemorySpaceMap;
>   ...
> 1730BuildMemoryDescriptor (Descriptor, Entry);
> 
> Tests:
>   Pass build and boot to shell.
> 
> Cc: Hao Wu 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> index 8bbdf7129f..a76d2db73c 100644
> --- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> +++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> @@ -1719,7 +1719,7 @@ CoreGetMemorySpaceMap (
>  // AllocatePool() called below has to be running outside the GCD lock.
>  //
>  DescriptorCount = CoreCountGcdMapEntry ();
> -if (DescriptorCount == *NumberOfDescriptors) {
> +if (DescriptorCount == *NumberOfDescriptors && *MemorySpaceMap !=
> NULL) {

Seems good to me.
Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

>//
>// Fill in the MemorySpaceMap if no memory space map change.
>//
> --
> 2.16.2.windows.1

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


[edk2] [PATCH] MdeModulePkg/Core: fix an issue of potential NULL pointer access

2018-10-29 Thread Jian J Wang
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1286

This issue is introduced by bb685071c2602cf786ea84c69bbebf2158194a38.

The *MemorySpaceMap assigned with NULL (line 1710) value might be
accessed (line 1726/1730) without any sanity check. Although it won't
happen in practice because of line 1722, we still need to add check
against NULL to make static code analyzer happy.

1710  *MemorySpaceMap   = NULL;
  ...
1722  if (DescriptorCount == *NumberOfDescriptors) {
  ...
1726Descriptor = *MemorySpaceMap;
  ...
1730BuildMemoryDescriptor (Descriptor, Entry);

Tests:
  Pass build and boot to shell.

Cc: Hao Wu 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
index 8bbdf7129f..a76d2db73c 100644
--- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
+++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
@@ -1719,7 +1719,7 @@ CoreGetMemorySpaceMap (
 // AllocatePool() called below has to be running outside the GCD lock.
 //
 DescriptorCount = CoreCountGcdMapEntry ();
-if (DescriptorCount == *NumberOfDescriptors) {
+if (DescriptorCount == *NumberOfDescriptors && *MemorySpaceMap != NULL) {
   //
   // Fill in the MemorySpaceMap if no memory space map change.
   //
-- 
2.16.2.windows.1

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


Re: [edk2] [PATCH v2 0/4] Conflict Detection for Tcp and PxeBc Driver

2018-10-29 Thread Fu, Siyuan
Reviewed-by: Fu Siyuan 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Songpeng Li
> Sent: Monday, October 29, 2018 1:48 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin 
> Subject: [edk2] [PATCH v2 0/4] Conflict Detection for Tcp and PxeBc Driver
> 
> v2: Modify files:
>   UefiPxeBcDxe.inf from MdeModulePkg
>   UefiPxeBcDxe.inf from NetworkPkg
>   tag protocol guid should be marked as BY_START
> 
> Please refer to the log message of each commit for more details.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1278
> Cc: Ye Ting 
> Cc: Wu Jiaxin 
> Cc: Fu Siyuan 
> Songpeng Li (4):
>   MdeModulePkg: Add Tag Protocol for PxeBc Driver Conflict Detection.
>   MdeModulePkg/UefiPxeBcDxe: Add Conflict Detection Process.
>   NetworkPkg/UefiPxeBcDxe: Add Conflict Detection Process.
>   NetworkPkg/TcpDxe: Modify the Version of Driver Binding Protocol
> 
>  MdeModulePkg/Include/Protocol/PxeBcTag.h  | 26 
>  MdeModulePkg/MdeModulePkg.dec |  5 +++
>  .../Network/UefiPxeBcDxe/PxeBcDriver.c| 19 -
>  .../Network/UefiPxeBcDxe/PxeBcImpl.h  |  3 +-
>  .../Network/UefiPxeBcDxe/UefiPxeBcDxe.inf |  1 +
>  NetworkPkg/TcpDxe/TcpDriver.c |  4 +-
>  NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c | 42 ++-
>  NetworkPkg/UefiPxeBcDxe/PxeBcImpl.h   |  1 +
>  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf  |  1 +
>  9 files changed, 96 insertions(+), 6 deletions(-)
>  create mode 100644 MdeModulePkg/Include/Protocol/PxeBcTag.h
> 
> --
> 2.18.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 0/4] Conflict Detection for Tcp and PxeBc Driver

2018-10-29 Thread Wu, Jiaxin
Looks good to me. 

Series  Reviewed-by: Wu Jiaxin 

Thanks,
Jiaxin 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Songpeng Li
> Sent: Monday, October 29, 2018 1:48 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin 
> Subject: [edk2] [PATCH v2 0/4] Conflict Detection for Tcp and PxeBc Driver
> 
> v2: Modify files:
>   UefiPxeBcDxe.inf from MdeModulePkg
>   UefiPxeBcDxe.inf from NetworkPkg
>   tag protocol guid should be marked as BY_START
> 
> Please refer to the log message of each commit for more details.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1278
> Cc: Ye Ting 
> Cc: Wu Jiaxin 
> Cc: Fu Siyuan 
> Songpeng Li (4):
>   MdeModulePkg: Add Tag Protocol for PxeBc Driver Conflict Detection.
>   MdeModulePkg/UefiPxeBcDxe: Add Conflict Detection Process.
>   NetworkPkg/UefiPxeBcDxe: Add Conflict Detection Process.
>   NetworkPkg/TcpDxe: Modify the Version of Driver Binding Protocol
> 
>  MdeModulePkg/Include/Protocol/PxeBcTag.h  | 26 
>  MdeModulePkg/MdeModulePkg.dec |  5 +++
>  .../Network/UefiPxeBcDxe/PxeBcDriver.c| 19 -
>  .../Network/UefiPxeBcDxe/PxeBcImpl.h  |  3 +-
>  .../Network/UefiPxeBcDxe/UefiPxeBcDxe.inf |  1 +
>  NetworkPkg/TcpDxe/TcpDriver.c |  4 +-
>  NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c | 42 ++-
>  NetworkPkg/UefiPxeBcDxe/PxeBcImpl.h   |  1 +
>  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf  |  1 +
>  9 files changed, 96 insertions(+), 6 deletions(-)
>  create mode 100644 MdeModulePkg/Include/Protocol/PxeBcTag.h
> 
> --
> 2.18.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel