Re: [edk2] [Patch 2/3] UefiCpuPkg/S3Resume2Pei: Send S3 resume finished event to SmmCore.

[Dong, Eric]

Hi Ray,

I think we can just base on DXE phase bits to prepare the communication buffer. 
I send new patches base on it. please check them.

Thanks,
Eric

-Original Message-
From: Ni, Ruiyu 
Sent: Wednesday, October 11, 2017 11:25 AM
To: Dong, Eric ; edk2-devel@lists.01.org
Cc: Yao, Jiewen 
Subject: RE: [Patch 2/3] UefiCpuPkg/S3Resume2Pei: Send S3 resume finished event 
to SmmCore.

Eric,
We may have 4 combinations for PEI DXE CPU architecture:
1. 32bit PEI + 32bit DXE: sizeof (UINTN) == sizeof (UINT32) && NOT 
PcdDxeIplSwitchToLongMode
2. 32bit PEI + 64bit DXE: sizeof (UINTN) == sizeof (UINT32) && 
PcdDxeIplSwitchToLongMode
3. 64bit PEI + 32bit DXE: NA!!!
4. 64bit PEI + 64bit DXE: sizeof (UINTN) != sizeof (UINT32) && NOT 
PcdDxeIplSwitchToLongMode

For #4, your code treats MessageLength as 4-byte, but actually it should be 
8-byte.
So how about we just check PcdDxeIplSwitchToLongMode, when it's FALSE, sizeof 
(MessageLength) equals to sizeof (UINTN).
Otherwise, sizeof (MessageLength) equals to 8.

So you only need to define:
> +typedef struct {
> +  EFI_GUID  HeaderGuid;
> +  UINT64MessageLength;
> +  UINT8 Data[1];
> +} EFI_SMM_COMMUNICATE_HEADER_IA64;

And I recommend to change the structure name to X64_EFI_SMM_COMMUNICATE_HEADER 
or
IA64_EFI_SMM_COMMUNICATE_HEADER. I am neutral using X64 or IA64, but don't want 
to have EFI_ in the beginning.

Thanks/Ray

> -Original Message-
> From: Dong, Eric
> Sent: Wednesday, October 11, 2017 10:23 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Yao, Jiewen 
> Subject: [Patch 2/3] UefiCpuPkg/S3Resume2Pei: Send S3 resume finished
> event to SmmCore.
> 
> Driver will send S3 resume finished event to SmmCore through communicate
> buffer after it signals EndOfPei event.
> 
> Cc: Ruiyu Ni 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c  | 85
> ++
>  .../Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf   |  4 +
>  2 files changed, 89 insertions(+)
> 
> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> index e53ed21..8350eb9 100644
> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> @@ -28,6 +28,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +#include 
> 
>  #include 
>  #include 
> @@ -151,6 +154,23 @@ typedef union {
>UINT64Uint64;
>  } PAGE_TABLE_1G_ENTRY;
> 
> +//
> +// Define two type of smm communicate headers.
> +// One for 32 bits  PEI + 64 bits DXE, the other for 32 bits PEI + 32 bits 
> DXE
> case.
> +//
> +typedef struct {
> +
> +  EFI_GUID  HeaderGuid;
> +  UINT32MessageLength;
> +  UINT8 Data[1];
> +} EFI_SMM_COMMUNICATE_HEADER_IA32;
> +
> +typedef struct {
> +  EFI_GUID  HeaderGuid;
> +  UINT64MessageLength;
> +  UINT8 Data[1];
> +} EFI_SMM_COMMUNICATE_HEADER_IA64;
> +
>  #pragma pack()
> 
>  //
> @@ -430,6 +450,65 @@ IsLongModeWakingVector (  }
> 
>  /**
> +  Send EndOfS3Resume event to SmmCore through communication buffer
> way.
> +
> +  @retval  EFI_SUCCESS Return send the event success.
> +**/
> +EFI_STATUS
> +SignalEndOfS3Resume (
> +  VOID
> +  )
> +{
> +  EFI_STATUS Status;
> +  EFI_PEI_SMM_COMMUNICATION_PPI  *SmmCommunicationPpi;
> +  UINTN  CommSize;
> +  EFI_SMM_COMMUNICATE_HEADER_IA32Header32;
> +  EFI_SMM_COMMUNICATE_HEADER_IA64Header64;
> +  VOID   *CommBuffer;
> +
> +  DEBUG ((EFI_D_INFO, "SignalEndOfS3Resume - Enter\n"));
> +
> +  //
> +  // Detect whether current is 32 bits PEI + 64 bits DXE case.
> +  //
> +  if ((sizeof(UINTN) == sizeof(UINT32)) && (FeaturePcdGet
> (PcdDxeIplSwitchToLongMode))) {
> +CommBuffer = 
> +Header64.MessageLength = 0;
> +CommSize = sizeof (EFI_SMM_COMMUNICATE_HEADER_IA64);
> +  } else {
> +CommBuffer = 
> +Header32.MessageLength = 0;
> +CommSize = sizeof (EFI_SMM_COMMUNICATE_HEADER_IA32);
> +  }
> +  CopyGuid (CommBuffer, );
> +
> +  //
> +  // Get needed resource
> +  //
> +  Status = PeiServicesLocatePpi (
> + ,
> + 0,
> + NULL,
> + (VOID **)
> + );
> +  ASSERT_EFI_ERROR (Status);
> +
> +  //
> +  // Send command
> +  //
> +  Status = SmmCommunicationPpi->Communicate (
> +  SmmCommunicationPpi,
> +  (VOID *)CommBuffer,
> +  
> +  );
> +  ASSERT_EFI_ERROR (Status);
> +
> +  DEBUG ((EFI_D_INFO, "SignalEndOfS3Resume - Exit (%r)\n", Status));
> +
> +  return Status;
> +}
> +
> +/**
>Jump to OS waking vector.
>The function 

[edk2] [Patch v2 1/3] MdeModulePkg/SmmEndOfS3Resume.h: Add new protocol definition.

[Eric Dong]

Add gEdkiiSmmEndOfS3ResumeProtocolGuid which used by SmmCore to
notify smm drives that S3 resume has finished.

Cc: Ruiyu Ni 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h | 26 
 MdeModulePkg/MdeModulePkg.dec|  3 +++
 2 files changed, 29 insertions(+)
 create mode 100644 MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h

diff --git a/MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h 
b/MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h
new file mode 100644
index 000..9716f6a
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h
@@ -0,0 +1,26 @@
+/** @file
+  This Protocol will be installed at the end of S3 resume phase in SMM 
environment. 
+  It allows for smm drivers to hook this point and do the requried tasks.
+
+  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  This program and the accompanying materials  
+  are licensed and made available under the terms and conditions of the BSD 
License 
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php   
 
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
 
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED. 
+
+**/
+
+#ifndef __SMM_END_OF_S3_RESUME_H__
+#define __SMM_END_OF_S3_RESUME_H__
+
+#define EDKII_SMM_END_OF_S3_RESUME_PROTOCOL_GUID \
+  { \
+0x96f5296d, 0x05f7, 0x4f3c, {0x84, 0x67, 0xe4, 0x56, 0x89, 0x0e, 0x0c, 
0xb5 } \
+  }
+
+extern EFI_GUID gEdkiiSmmEndOfS3ResumeProtocolGuid;
+
+#endif
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index a3c0633..216e4f9 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -556,6 +556,9 @@
   ## Include/Protocol/IoMmu.h
   gEdkiiIoMmuProtocolGuid = { 0x4e939de9, 0xd948, 0x4b0f, { 0x88, 0xed, 0xe6, 
0xe1, 0xce, 0x51, 0x7c, 0x1e } }
 
+  ## Include/Protocol/SmmEndofS3Resume.h
+  gEdkiiSmmEndOfS3ResumeProtocolGuid = { 0x96f5296d, 0x05f7, 0x4f3c, {0x84, 
0x67, 0xe4, 0x56, 0x89, 0x0e, 0x0c, 0xb5 } }
+
 #
 # [Error.gEfiMdeModulePkgTokenSpaceGuid]
 #   0x8001 | Invalid value provided.
-- 
2.7.0.windows.1

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

[edk2] [Patch v2 2/3] UefiCpuPkg/S3Resume2Pei: Send S3 resume finished event to SmmCore.

[Eric Dong]

Driver will send S3 resume finished event to SmmCore through communicate
buffer after it signals EndOfPei event.

V2 Changes:
1. Change structures name to avoid they start with EFI_.
2. Base on DXE phase bits to provide communication buffer, current implement
check both PEI and DXE phase.

Cc: Ruiyu Ni 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c  | 87 ++
 .../Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf   |  4 +
 2 files changed, 91 insertions(+)

diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index e53ed21..56f7b37 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
@@ -28,6 +28,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include 
 
 #include 
 #include 
@@ -151,6 +154,22 @@ typedef union {
   UINT64Uint64;
 } PAGE_TABLE_1G_ENTRY;
 
+//
+// Define two type of smm communicate headers.
+// One for 32 bits  PEI + 64 bits DXE, the other for 32 bits PEI + 32 bits DXE 
case.
+//
+typedef struct {
+  EFI_GUID  HeaderGuid;
+  UINT32MessageLength;
+  UINT8 Data[1];
+} IA32_EFI_SMM_COMMUNICATE_HEADER;
+
+typedef struct {
+  EFI_GUID  HeaderGuid;
+  UINT64MessageLength;
+  UINT8 Data[1];
+} IA64_EFI_SMM_COMMUNICATE_HEADER;
+
 #pragma pack()
 
 //
@@ -430,6 +449,68 @@ IsLongModeWakingVector (
 }
 
 /**
+  Send EndOfS3Resume event to SmmCore through communication buffer way.
+
+  @retval  EFI_SUCCESS Return send the event success.
+**/
+EFI_STATUS
+SignalEndOfS3Resume (
+  VOID
+  )
+{
+  EFI_STATUS Status;
+  EFI_PEI_SMM_COMMUNICATION_PPI  *SmmCommunicationPpi;
+  UINTN  CommSize;
+  IA32_EFI_SMM_COMMUNICATE_HEADERHeader32;
+  IA64_EFI_SMM_COMMUNICATE_HEADERHeader64;
+  VOID   *CommBuffer;
+
+  DEBUG ((EFI_D_INFO, "SignalEndOfS3Resume - Enter\n"));
+
+  //
+  // This buffer consumed in DXE phase, so base on DXE mode to prepare 
communicate buffer.
+  // Detect whether DXE is 64 bits mode.
+  // if (sizeof(UINTN) == sizeof(UINT64), PEI already 64 bits, assume DXE also 
64 bits.
+  // or (FeaturePcdGet (PcdDxeIplSwitchToLongMode)), Dxe will switch to 64 
bits.
+  //
+  if ((sizeof(UINTN) == sizeof(UINT64)) || (FeaturePcdGet 
(PcdDxeIplSwitchToLongMode))) {
+CommBuffer = 
+Header64.MessageLength = 0;
+CommSize = sizeof (IA64_EFI_SMM_COMMUNICATE_HEADER);
+  } else {
+CommBuffer = 
+Header32.MessageLength = 0;
+CommSize = sizeof (IA32_EFI_SMM_COMMUNICATE_HEADER);
+  }
+  CopyGuid (CommBuffer, );
+
+  //
+  // Get needed resource
+  //
+  Status = PeiServicesLocatePpi (
+ ,
+ 0,
+ NULL,
+ (VOID **)
+ );
+  ASSERT_EFI_ERROR (Status);
+
+  //
+  // Send command
+  //
+  Status = SmmCommunicationPpi->Communicate (
+  SmmCommunicationPpi,
+  (VOID *)CommBuffer,
+  
+  );
+  ASSERT_EFI_ERROR (Status);
+
+  DEBUG ((EFI_D_INFO, "SignalEndOfS3Resume - Exit (%r)\n", Status));
+
+  return Status;
+}
+
+/**
   Jump to OS waking vector.
   The function will install boot script done PPI, report S3 resume status 
code, and then jump to OS waking vector.
 
@@ -504,6 +585,12 @@ S3ResumeBootOs (
   ASSERT_EFI_ERROR (Status);
 
   //
+  // Signal EndOfS3Resume event.
+  //
+  Status = SignalEndOfS3Resume ();
+  ASSERT_EFI_ERROR (Status);
+
+  //
   // report status code on S3 resume
   //
   REPORT_STATUS_CODE (EFI_PROGRESS_CODE, EFI_SOFTWARE_PEI_MODULE | 
EFI_SW_PEI_PC_OS_WAKE);
diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
index d514523..943f114 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
@@ -85,6 +85,10 @@
   gPeiSmmAccessPpiGuid  ## SOMETIMES_CONSUMES
   gPeiPostScriptTablePpiGuid## SOMETIMES_PRODUCES
   gEfiEndOfPeiSignalPpiGuid ## SOMETIMES_PRODUCES
+  gEfiPeiSmmCommunicationPpiGuid## SOMETIMES_CONSUMES
+
+[Protocols]
+  gEdkiiSmmEndOfS3ResumeProtocolGuid## SOMETIMES_CONSUMES
 
 [FeaturePcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode ## CONSUMES
-- 
2.7.0.windows.1

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

[edk2] [Patch v2 3/3] MdeModulePkg/PiSmmCore: Install Protocol when S3 resume finished.

[Eric Dong]

Install EdkiiSmmEndOfS3ResumeProtocol when S3 resume finished.
S3ResumePei will send S3 resume finished event to SmmCore through
communication buffer.

Cc: Ruiyu Ni 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c   | 55 +++
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h   | 24 ++
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf |  1 +
 3 files changed, 73 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
index 9e4390e..aa44933 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
@@ -75,13 +75,14 @@ BOOLEAN  mInLegacyBoot = FALSE;
 // Table of SMI Handlers that are registered by the SMM Core when it is 
initialized
 //
 SMM_CORE_SMI_HANDLERS  mSmmCoreSmiHandlers[] = {
-  { SmmDriverDispatchHandler,   ,  NULL, TRUE 
 },
-  { SmmReadyToLockHandler,  , NULL, TRUE 
}, 
-  { SmmLegacyBootHandler,   ,   NULL, 
FALSE },
-  { SmmExitBootServicesHandler, , NULL, 
FALSE },
-  { SmmReadyToBootHandler,  ,  NULL, 
FALSE },
-  { SmmEndOfDxeHandler, ,NULL, TRUE 
},
-  { NULL,   NULL,   NULL, 
FALSE }
+  { SmmDriverDispatchHandler,   ,   NULL, 
TRUE  },
+  { SmmReadyToLockHandler,  ,  NULL, 
TRUE }, 
+  { SmmLegacyBootHandler,   ,NULL, 
FALSE },
+  { SmmExitBootServicesHandler, ,  NULL, 
FALSE },
+  { SmmReadyToBootHandler,  ,   NULL, 
FALSE },
+  { SmmEndOfDxeHandler, , NULL, 
TRUE },
+  { SmmEndOfS3ResumeHandler,, NULL, 
FALSE },
+  { NULL,   NULL,NULL, 
FALSE }
 };
 
 UINTN   mFullSmramRangeCount;
@@ -383,6 +384,46 @@ SmmEndOfDxeHandler (
 }
 
 /**
+  Software SMI handler that is called when the EndOfS3Resume event is trigged.
+  This function installs the SMM EndOfS3Resume Protocol so SMM Drivers are 
informed that
+  S3 resume has finished.
+
+  @param  DispatchHandle  The unique handle assigned to this handler by 
SmiHandlerRegister().
+  @param  Context Points to an optional handler context which was 
specified when the handler was registered.
+  @param  CommBuffer  A pointer to a collection of data in memory that will
+  be conveyed from a non-SMM environment into an SMM 
environment.
+  @param  CommBufferSize  The size of the CommBuffer.
+
+  @return Status Code
+
+**/
+EFI_STATUS
+EFIAPI
+SmmEndOfS3ResumeHandler (
+  IN EFI_HANDLE  DispatchHandle,
+  IN CONST VOID  *Context,OPTIONAL
+  IN OUT VOID*CommBuffer, OPTIONAL
+  IN OUT UINTN   *CommBufferSize  OPTIONAL
+  )
+{
+  EFI_STATUS  Status;
+  EFI_HANDLE  SmmHandle;
+
+  DEBUG ((EFI_D_INFO, "SmmEndOfS3ResumeHandler\n"));
+  //
+  // Install SMM EndOfDxe protocol
+  //
+  SmmHandle = NULL;
+  Status = SmmInstallProtocolInterface (
+ ,
+ ,
+ EFI_NATIVE_INTERFACE,
+ NULL
+ );
+  return Status;
+}
+
+/**
   Determine if two buffers overlap in memory.
 
   @param[in] Buff1  Pointer to first buffer
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
index b6f815c..6cc824b 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -802,6 +803,29 @@ SmmReadyToBootHandler (
   );
 
 /**
+  Software SMI handler that is called when the EndOfS3Resume event is trigged.
+  This function installs the SMM EndOfS3Resume Protocol so SMM Drivers are 
informed that
+  S3 resume has finished.
+
+  @param  DispatchHandle  The unique handle assigned to this handler by 
SmiHandlerRegister().
+  @param  Context Points to an optional handler context which was 
specified when the handler was registered.
+  @param  CommBuffer  A pointer to a collection of data in memory that will
+  be conveyed from a non-SMM environment into an SMM 
environment.
+  @param  CommBufferSize  The size of the CommBuffer.
+
+  @return Status Code
+
+**/
+EFI_STATUS
+EFIAPI
+SmmEndOfS3ResumeHandler (
+  IN EFI_HANDLE  DispatchHandle,
+  IN CONST VOID  *Context,OPTIONAL
+  IN OUT VOID*CommBuffer, OPTIONAL
+  IN OUT UINTN   *CommBufferSize  OPTIONAL
+  );
+
+/**
   Place holder function until all the SMM System Table Service are available.
 
   @param  Arg1   Undefined
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
index 95e34bd..a724189 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf

[edk2] [Patch v2 0/3] Add SmmEndOfS3Resume event.

[Eric Dong]

This patch series add new SmmEndOfS3Resume event which required by some
SMM drivers. 
It will implmented by SmmCore to install the gEdkiiSmmEndOfS3ResumeProtocolGuid
Protocol. Smm drivers can install this protocol's notification functions to 
hoot this envet.
It will be trigged right after the EndOfPei event in S3 resume phase.

V2 Changes: Only change patch 2/3
1. Change structures name to avoid they start with EFI_.
2. Base on DXE phase bits to provide communication buffer, current implement
check both PEI and DXE phase.

Cc: Ruiyu Ni 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 

Eric Dong (3):
  MdeModulePkg/SmmEndOfS3Resume.h: Add new protocol definition.
  UefiCpuPkg/S3Resume2Pei: Send S3 resume finished event to SmmCore.
  MdeModulePkg/PiSmmCore: Install Protocol when S3 resume finished.

 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c| 55 --
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h| 24 ++
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf  |  1 +
 MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h   | 31 
 MdeModulePkg/MdeModulePkg.dec  |  3 +
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c  | 85 ++
 .../Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf   |  4 +
 7 files changed, 196 insertions(+), 7 deletions(-)
 create mode 100644 MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h

-- 
2.7.0.windows.1

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

Re: [edk2] [Patch 1/3] BaseTools: GenFfs support to get alignment value from SectionFile

[Gao, Liming]

PeFileBuffer should free in the end of the function.

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Yonghong Zhu
>Sent: Friday, September 29, 2017 9:23 AM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming 
>Subject: [edk2] [Patch 1/3] BaseTools: GenFfs support to get alignment value
>from SectionFile
>
>Update GenFfs tool to get alignment value from SectionFile when use
>the new option -n 0.
>
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/C/GenFfs/GenFfs.c | 127
>-
> 1 file changed, 125 insertions(+), 2 deletions(-)
>
>diff --git a/BaseTools/Source/C/GenFfs/GenFfs.c
>b/BaseTools/Source/C/GenFfs/GenFfs.c
>index cb16f38..26a3c88 100644
>--- a/BaseTools/Source/C/GenFfs/GenFfs.c
>+++ b/BaseTools/Source/C/GenFfs/GenFfs.c
>@@ -10,10 +10,17 @@ http://opensource.org/licenses/bsd-license.php
> THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS
>OR IMPLIED.
>
> **/
>
>+#ifndef __GNUC__
>+#include 
>+#include 
>+#include 
>+#include 
>+#endif
>+
> #include 
> #include 
> #include 
>
> #include 
>@@ -22,10 +29,12 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
>KIND, EITHER EXPRESS OR IMPLIED.
> #include 
>
> #include "CommonLib.h"
> #include "ParseInf.h"
> #include "EfiUtilityMsgs.h"
>+#include "FvLib.h"
>+#include "PeCoffLib.h"
>
> #define UTILITY_NAME"GenFfs"
> #define UTILITY_MAJOR_VERSION   0
> #define UTILITY_MINOR_VERSION   1
>
>@@ -151,11 +160,12 @@ Returns:
> 128K,256K,512K,1M,2M,4M,8M,16M\n");
>   fprintf (stdout, "  -i SectionFile, --sectionfile SectionFile\n\
> Section file will be contained in this FFS file.\n");
>   fprintf (stdout, "  -n SectionAlign, --sectionalign SectionAlign\n\
> SectionAlign points to section alignment, which 
> support\n\
>-the alignment scope 1~16M. It is specified together\n\
>+the alignment scope 0~16M. If SectionAlign is 
>specified as 0,
>tool\n\
>+get alignment value from SectionFile. It is specified 
>together\n\
> with sectionfile to point its alignment in FFS 
> file.\n");
>   fprintf (stdout, "  -v, --verbose Turn on verbose output with
>informational messages.\n");
>   fprintf (stdout, "  -q, --quiet   Disable all messages except key 
> message
>and fatal error\n");
>   fprintf (stdout, "  -d, --debug level Enable debug messages, at input 
> debug
>level.\n");
>   fprintf (stdout, "  --version Show program's version number and
>exit.\n");
>@@ -455,10 +465,101 @@ Returns:
> *BufferLength = Size;
> return EFI_SUCCESS;
>   }
> }
>
>+EFI_STATUS
>+FfsRebaseImageRead (
>+IN  VOID*FileHandle,
>+IN  UINTN   FileOffset,
>+IN OUT  UINT32  *ReadSize,
>+OUT VOID*Buffer
>+)
>+  /*++
>+
>+Routine Description:
>+
>+Support routine for the PE/COFF Loader that reads a buffer from a
>PE/COFF file
>+
>+Arguments:
>+
>+   FileHandle - The handle to the PE/COFF file
>+
>+   FileOffset - The offset, in bytes, into the file to read
>+
>+   ReadSize   - The number of bytes to read from the file starting at 
>FileOffset
>+
>+   Buffer - A pointer to the buffer to read the data into.
>+
>+   Returns:
>+
>+   EFI_SUCCESS - ReadSize bytes of data were read into Buffer from the
>PE/COFF file starting at FileOffset
>+
>+   --*/
>+{
>+  CHAR8   *Destination8;
>+  CHAR8   *Source8;
>+  UINT32  Length;
>+
>+  Destination8  = Buffer;
>+  Source8   = (CHAR8 *) ((UINTN) FileHandle + FileOffset);
>+  Length= *ReadSize;
>+  while (Length--) {
>+*(Destination8++) = *(Source8++);
>+  }
>+
>+  return EFI_SUCCESS;
>+}
>+
>+STATIC
>+EFI_STATUS
>+GetAlignmentFromFile(char *InFile, UINT32 *Alignment)
>+  /*++
>+InFile is input file for getting alignment
>+return the alignment
>+--*/
>+{
>+  FILE   *InFileHandle;
>+  UINT8  *PeFileBuffer;
>+  UINTN  PeFileSize;
>+  UINT32 CurSecHdrSize;
>+  PE_COFF_LOADER_IMAGE_CONTEXT   ImageContext;
>+  EFI_COMMON_SECTION_HEADER  *CommonHeader;
>+  EFI_STATUS Status;
>+
>+  InFileHandle= NULL;
>+  PeFileBuffer= NULL;
>+
>+  memset (, 0, sizeof (ImageContext));
>+
>+  InFileHandle = fopen(LongFilePath(InFile), "rb");
>+  if (InFileHandle == NULL){
>+Error (NULL, 0, 0001, "Error opening file", InFile);
>+return EFI_ABORTED;
>+  }
>+  PeFileSize = _filelength (fileno(InFileHandle));
>+  PeFileBuffer = (UINT8 *) malloc (PeFileSize);
>+  if (PeFileBuffer == NULL) {
>+fclose (InFileHandle);
>+Error(NULL, 0, 4001, 

Re: [edk2] [platforms: PATCH 01/13] Marvell/Armada: Introduce platform initialization driver

[Marcin Wojtas]

2017-10-10 22:36 GMT+02:00 Ard Biesheuvel :
> On 10 October 2017 at 16:26, Leif Lindholm  wrote:
>> On Tue, Oct 10, 2017 at 05:06:42PM +0200, Marcin Wojtas wrote:
>>> 2017-10-10 17:03 GMT+02:00 Leif Lindholm :
>>> > On Tue, Oct 10, 2017 at 04:45:10PM +0200, Marcin Wojtas wrote:
>>> >> Hi Leif,
>>> >>
>>> >> 2017-10-10 16:37 GMT+02:00 Leif Lindholm :
>>> >> > On Mon, Oct 09, 2017 at 07:00:50PM +0200, Marcin Wojtas wrote:
>>> >> >> In order to enable modification of dynamic PCD's for the libraries
>>> >> >> and DXE drivers, this patch introduces new driver. It is
>>> >> >> executed prior to other drivers. Mpp, ComPhy and Utmi libraries
>>> >> >> initialization were moved from PrePi stage to DXE.
>>> >> >>
>>> >> >> To force the correct driver dispatch sequence, introduce a protocol 
>>> >> >> GUID
>>> >> >> and install the protocol as a NULL protocol when PlatInitDxe executes.
>>> >> >>
>>> >> >> Contributed-under: TianoCore Contribution Agreement 1.1
>>> >> >> Signed-off-by: Marcin Wojtas 
>>> >> >> Signed-off-by: Ard Biesheuvel 
>>> >> >
>>> >> > What does Ard's Signed-off-by signify here?
>>> >> > (I know the authorship on some of these is a bit blurred, since you've
>>> >> > been working together, but I'd like to be clear.)
>>> >>
>>> >> These were the lines, introducing/installing protocol GUID stuff. It
>>> >> was in a small separate patch, but I squashed it into bigger one.
>>> >
>>> > Personally, I would in this instance do:
>>> > 
>>> > Ard
>>> > 
>>> >
>>> > It's verbose, but reasonably clear.
>>> >
>>>
>>> How about:
>>>
>>> In order to enable modification of dynamic PCD's for the libraries
>>> and DXE drivers, this patch introduces new driver. It is
>>> executed prior to other drivers. Mpp, ComPhy and Utmi libraries
>>> initialization were moved from PrePi stage to DXE.
>>>
>>> Signed-off-by: Marcin Wojtas 
>>>
>>> To force the correct driver dispatch sequence, introduce a protocol GUID
>>> and install the protocol as a NULL protocol when PlatInitDxe executes.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Ard Biesheuvel 
>>> Signed-off-by: Marcin Wojtas 
>>>
>>> ?
>>>
>>> Was that, what you meant?
>>
>> I think Contibuted-under: still needs to come first.
>>
>> I don't think we have an explicit policy for how to deal with
>> multi-contributor patches. The ones we do see tend to just keep a
>> single commit message and list the contributors.
>>
>> In Linux. it would be something like
>> Signed-off-by: Marcin Wojtas 
>> [Introduce protocol GUID to force correct driver dispatch order]
>> Signed-off-by: Ard Biesheuvel 
>> Signed-off-by: Marcin Wojtas 
>>
>> I would be quite happy to use the same format here.
>>
>
> Well, Tianocore still conflates authorship with a statement regarding
> the origin of the contribution. I wonder how this is supposed to work
> when Linaro engineers such as myself contribute code that was authored
> by engineers working in member companies, e.g., Socionext. The license
> and the contract that company has with Linaro give me the right to
> contribute that code, but that does not make me the author, and I
> cannot add a Signed-off-by that wasn't present when we received the
> code (even if I knew the name of the author)

I think it's fairly easy thing, needlessly twisted... How does above
reflect the requirement to add contributor sign-off to someone else's
patch (with his authorship and original sign-off - should they be
removed?)?

Anyway, let's make a quick decision here - should I submit patch with
linux-like signatures and description? Or should I split the patches?

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

Re: [edk2] [Patch] BaseTools: Fix the Keyword error for in FDF File

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: Zhu, Yonghong
>Sent: Monday, October 09, 2017 9:37 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming 
>Subject: [Patch] BaseTools: Fix the Keyword error for  in
>FDF File
>
>current in FDF spec 3.6 [FV] section it use "FV_EXT_ENTRY_TYPE" as
>Keyword for , while in the code it use "FV_EXT_ENTRY".
>To keep compatibility, this patch support both keyword in the code
>first.
>
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yonghong Zhu 
>---
> 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 b95afc7..0190be8 100644
>--- a/BaseTools/Source/Python/GenFds/FdfParser.py
>+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
>@@ -2363,11 +2363,11 @@ class FdfParser:
>
> return True
>
> def __GetFvExtEntryStatement(self, FvObj):
>
>-if not self.__IsKeyword( "FV_EXT_ENTRY"):
>+if not (self.__IsKeyword( "FV_EXT_ENTRY") or
>self.__IsKeyword( "FV_EXT_ENTRY_TYPE")):
> return False
>
> if not self.__IsKeyword ("TYPE"):
> raise Warning("expected 'TYPE'", self.FileName,
>self.CurrentLineNumber)
>
>--
>2.6.1.windows.1

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

Re: [edk2] [Patch] BaseTools: Fix the bug 'DSC DEFAULT' in report wrongly use FDF value

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: Zhu, Yonghong
>Sent: Monday, October 09, 2017 9:37 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming 
>Subject: [Patch] BaseTools: Fix the bug 'DSC DEFAULT' in report wrongly use
>FDF value
>
>current the PCD value in DSC file may be override by FDF file, then it
>cause the 'DSC DEFAULT' in build report wrongly display the FDF value
>but not the DSC file's value.
>This patch add a attribute DscDefaultValue for PcdClassObject to save
>the actual DSC file's PCD value and use this value to display for 'DSC
>DEFAULT'.
>
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/Python/Workspace/BuildClassObject.py |  7 +--
> .../Source/Python/Workspace/WorkspaceDatabase.py  | 19 +
>--
> BaseTools/Source/Python/build/BuildReport.py  |  7 ---
> 3 files changed, 18 insertions(+), 15 deletions(-)
>
>diff --git a/BaseTools/Source/Python/Workspace/BuildClassObject.py
>b/BaseTools/Source/Python/Workspace/BuildClassObject.py
>index ea26e5e..5fa497b 100644
>--- a/BaseTools/Source/Python/Workspace/BuildClassObject.py
>+++ b/BaseTools/Source/Python/Workspace/BuildClassObject.py
>@@ -1,9 +1,9 @@
> ## @file
> # This file is used to define each component of the build database
> #
>-# Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
>+# Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved.
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD
>License
> # which accompanies this distribution.  The full text of the license may be
>found at
> # http://opensource.org/licenses/bsd-license.php
> #
>@@ -42,11 +42,11 @@ from Common.BuildToolError import *
> # @var SkuInfoList:  To store value for SkuInfoList
> # @var IsOverrided:  To store value for IsOverrided
> # @var Phase:To store value for Phase, default is "DXE"
> #
> class PcdClassObject(object):
>-def __init__(self, Name = None, Guid = None, Type = None, DatumType =
>None, Value = None, Token = None, MaxDatumSize = None, SkuInfoList = {},
>IsOverrided = False, GuidValue = None, validateranges = [], validlists = [],
>expressions = []):
>+def __init__(self, Name = None, Guid = None, Type = None, DatumType =
>None, Value = None, Token = None, MaxDatumSize = None, SkuInfoList = {},
>IsOverrided = False, GuidValue = None, validateranges = [], validlists = [],
>expressions = [], IsDsc = False):
> self.TokenCName = Name
> self.TokenSpaceGuidCName = Guid
> self.TokenSpaceGuidValue = GuidValue
> self.Type = Type
> self.DatumType = DatumType
>@@ -60,10 +60,13 @@ class PcdClassObject(object):
> self.IsFromBinaryInf = False
> self.IsFromDsc = False
> self.validateranges = validateranges
> self.validlists = validlists
> self.expressions = expressions
>+self.DscDefaultValue = None
>+if IsDsc:
>+self.DscDefaultValue = Value
>
> ## Convert the class to a string
> #
> #  Convert each member of the class to string
> #  Organize to a signle line format string
>diff --git a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
>b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
>index b617221..2c4b973 100644
>--- a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
>+++ b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
>@@ -883,12 +883,12 @@ class DscBuildData(PlatformBuildClassObject):
> PcdValue,
> '',
> MaxDatumSize,
> {},
> False,
>-None
>-)
>+None,
>+IsDsc=True)
> return Pcds
>
> ## Retrieve dynamic PCD settings
> #
> #   @param  TypePCD type
>@@ -948,13 +948,13 @@ class DscBuildData(PlatformBuildClassObject):
> PcdValue,
> '',
> MaxDatumSize,
> {SkuName : SkuInfo},
> False,
>-None
>-)
>-
>+None,
>+IsDsc=True)
>+
> for pcd in Pcds.values():
>

Re: [edk2] [Patch 2/3] UefiCpuPkg/S3Resume2Pei: Send S3 resume finished event to SmmCore.

[Ni, Ruiyu]

Eric,
We may have 4 combinations for PEI DXE CPU architecture:
1. 32bit PEI + 32bit DXE: sizeof (UINTN) == sizeof (UINT32) && NOT 
PcdDxeIplSwitchToLongMode
2. 32bit PEI + 64bit DXE: sizeof (UINTN) == sizeof (UINT32) && 
PcdDxeIplSwitchToLongMode
3. 64bit PEI + 32bit DXE: NA!!!
4. 64bit PEI + 64bit DXE: sizeof (UINTN) != sizeof (UINT32) && NOT 
PcdDxeIplSwitchToLongMode

For #4, your code treats MessageLength as 4-byte, but actually it should be 
8-byte.
So how about we just check PcdDxeIplSwitchToLongMode, when it's FALSE, sizeof 
(MessageLength) equals to sizeof (UINTN).
Otherwise, sizeof (MessageLength) equals to 8.

So you only need to define:
> +typedef struct {
> +  EFI_GUID  HeaderGuid;
> +  UINT64MessageLength;
> +  UINT8 Data[1];
> +} EFI_SMM_COMMUNICATE_HEADER_IA64;

And I recommend to change the structure name to X64_EFI_SMM_COMMUNICATE_HEADER 
or
IA64_EFI_SMM_COMMUNICATE_HEADER. I am neutral using X64 or IA64, but don't want 
to have EFI_ in the beginning.

Thanks/Ray

> -Original Message-
> From: Dong, Eric
> Sent: Wednesday, October 11, 2017 10:23 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Yao, Jiewen 
> Subject: [Patch 2/3] UefiCpuPkg/S3Resume2Pei: Send S3 resume finished
> event to SmmCore.
> 
> Driver will send S3 resume finished event to SmmCore through communicate
> buffer after it signals EndOfPei event.
> 
> Cc: Ruiyu Ni 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c  | 85
> ++
>  .../Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf   |  4 +
>  2 files changed, 89 insertions(+)
> 
> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> index e53ed21..8350eb9 100644
> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> @@ -28,6 +28,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +#include 
> 
>  #include 
>  #include 
> @@ -151,6 +154,23 @@ typedef union {
>UINT64Uint64;
>  } PAGE_TABLE_1G_ENTRY;
> 
> +//
> +// Define two type of smm communicate headers.
> +// One for 32 bits  PEI + 64 bits DXE, the other for 32 bits PEI + 32 bits 
> DXE
> case.
> +//
> +typedef struct {
> +
> +  EFI_GUID  HeaderGuid;
> +  UINT32MessageLength;
> +  UINT8 Data[1];
> +} EFI_SMM_COMMUNICATE_HEADER_IA32;
> +
> +typedef struct {
> +  EFI_GUID  HeaderGuid;
> +  UINT64MessageLength;
> +  UINT8 Data[1];
> +} EFI_SMM_COMMUNICATE_HEADER_IA64;
> +
>  #pragma pack()
> 
>  //
> @@ -430,6 +450,65 @@ IsLongModeWakingVector (  }
> 
>  /**
> +  Send EndOfS3Resume event to SmmCore through communication buffer
> way.
> +
> +  @retval  EFI_SUCCESS Return send the event success.
> +**/
> +EFI_STATUS
> +SignalEndOfS3Resume (
> +  VOID
> +  )
> +{
> +  EFI_STATUS Status;
> +  EFI_PEI_SMM_COMMUNICATION_PPI  *SmmCommunicationPpi;
> +  UINTN  CommSize;
> +  EFI_SMM_COMMUNICATE_HEADER_IA32Header32;
> +  EFI_SMM_COMMUNICATE_HEADER_IA64Header64;
> +  VOID   *CommBuffer;
> +
> +  DEBUG ((EFI_D_INFO, "SignalEndOfS3Resume - Enter\n"));
> +
> +  //
> +  // Detect whether current is 32 bits PEI + 64 bits DXE case.
> +  //
> +  if ((sizeof(UINTN) == sizeof(UINT32)) && (FeaturePcdGet
> (PcdDxeIplSwitchToLongMode))) {
> +CommBuffer = 
> +Header64.MessageLength = 0;
> +CommSize = sizeof (EFI_SMM_COMMUNICATE_HEADER_IA64);
> +  } else {
> +CommBuffer = 
> +Header32.MessageLength = 0;
> +CommSize = sizeof (EFI_SMM_COMMUNICATE_HEADER_IA32);
> +  }
> +  CopyGuid (CommBuffer, );
> +
> +  //
> +  // Get needed resource
> +  //
> +  Status = PeiServicesLocatePpi (
> + ,
> + 0,
> + NULL,
> + (VOID **)
> + );
> +  ASSERT_EFI_ERROR (Status);
> +
> +  //
> +  // Send command
> +  //
> +  Status = SmmCommunicationPpi->Communicate (
> +  SmmCommunicationPpi,
> +  (VOID *)CommBuffer,
> +  
> +  );
> +  ASSERT_EFI_ERROR (Status);
> +
> +  DEBUG ((EFI_D_INFO, "SignalEndOfS3Resume - Exit (%r)\n", Status));
> +
> +  return Status;
> +}
> +
> +/**
>Jump to OS waking vector.
>The function will install boot script done PPI, report S3 resume status 
> code,
> and then jump to OS waking vector.
> 
> @@ -504,6 +583,12 @@ S3ResumeBootOs (
>ASSERT_EFI_ERROR (Status);
> 
>//
> +  // Signal EndOfS3Resume event.
> +  //
> +  Status = SignalEndOfS3Resume ();
> +  ASSERT_EFI_ERROR (Status);
> +
> +  //
>// report status code on S3 resume
>//
>REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
> EFI_SOFTWARE_PEI_MODULE | 

[edk2] [PATCH 5/5] UefiCpuPkg/PiSmmCpuDxeSmm: Disable page table protection

[Jian J Wang]

Heap guard feature will update page attributes frequently. The page table
should not set to be read-only if heap guard feature is enabled for SMM
mode. Otherwise this feature cannot work.

Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 1 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
index 099792e6ce..644709650c 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
@@ -159,6 +159,7 @@
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStaticPageTable   ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable   ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask   ## 
CONSUMES
 
 [Depex]
   gEfiMpServiceProtocolGuid
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
index 3dde80f9ba..4debce3a0f 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
@@ -902,7 +902,7 @@ SetPageTableAttributes (
   BOOLEAN   IsSplitted;
   BOOLEAN   PageTableSplitted;
 
-  if (!mCpuSmmStaticPageTable) {
+  if (!mCpuSmmStaticPageTable || (PcdGet8 (PcdHeapGuardPropertyMask) & BIT3 | 
BIT2) != 0) {
 return ;
   }
 
-- 
2.14.1.windows.1

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

[edk2] [PATCH 4/5] UefiCpuPkg/CpuDxe: Reduce debug message

[Jian J Wang]

Heap guard feature will frequently update page attributes. The debug message
in CpuDxe driver will slow down the boot performance noticeably. Changing the
debug level to DEBUG_POOL and DEBUG_PAGE to reduce the message output for
normal debug configuration.

Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 UefiCpuPkg/CpuDxe/CpuPageTable.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c b/UefiCpuPkg/CpuDxe/CpuPageTable.c
index d312eb66f8..5270a1124f 100644
--- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
+++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
@@ -442,8 +442,9 @@ ConvertPageEntryAttribute (
   *PageEntry = NewPageEntry;
   if (CurrentPageEntry != NewPageEntry) {
 *IsModified = TRUE;
-DEBUG ((DEBUG_INFO, "ConvertPageEntryAttribute 0x%lx", CurrentPageEntry));
-DEBUG ((DEBUG_INFO, "->0x%lx\n", NewPageEntry));
+DEBUG ((DEBUG_POOL | DEBUG_PAGE, "ConvertPageEntryAttribute 0x%lx",
+CurrentPageEntry));
+DEBUG ((DEBUG_POOL | DEBUG_PAGE, "->0x%lx\n", NewPageEntry));
   } else {
 *IsModified = FALSE;
   }
-- 
2.14.1.windows.1

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

[edk2] [PATCH 3/5] MdeModulePkg/MdeModulePkg.dec, .uni: Add heap guard related PCDs and string tokens

[Jian J Wang]

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/MdeModulePkg.dec | 57 ++
 MdeModulePkg/MdeModulePkg.uni | 58 +++
 2 files changed, 115 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index a3c0633ee1..99f5d88627 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -867,6 +867,63 @@
   # @ValidList  0x8006 | 0x03058002
   
gEfiMdeModulePkgTokenSpaceGuid.PcdErrorCodeSetVariable|0x03058002|UINT32|0x30001040
 
+  ## Indicates which type allocation need guard page.
+  # Below is bit mask for this PCD: (Order is same as UEFI spec)
+  #  EfiReservedMemoryType 0x0001
+  #  EfiLoaderCode 0x0002
+  #  EfiLoaderData 0x0004
+  #  EfiBootServicesCode   0x0008
+  #  EfiBootServicesData   0x0010
+  #  EfiRuntimeServicesCode0x0020
+  #  EfiRuntimeServicesData0x0040
+  #  EfiConventionalMemory 0x0080
+  #  EfiUnusableMemory 0x0100
+  #  EfiACPIReclaimMemory  0x0200
+  #  EfiACPIMemoryNVS  0x0400
+  #  EfiMemoryMappedIO 0x0800
+  #  EfiMemoryMappedIOPortSpace0x1000
+  #  EfiPalCode0x2000
+  #  EfiPersistentMemory   0x4000
+  #  OEM Reserved  0x4000
+  #  OS Reserved   0x8000
+  # e.g. LoaderCode+LoaderData+BootServicesCode+BootServicesData are needed, 
0x1E should be used.
+  # @Prompt The memory type mask for Page Guard.
+  gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPageType|0x0|UINT64|0x30001051
+
+  ## Indicates which type allocation need guard page.
+  # Below is bit mask for this PCD: (Order is same as UEFI spec)
+  #  EfiReservedMemoryType 0x0001
+  #  EfiLoaderCode 0x0002
+  #  EfiLoaderData 0x0004
+  #  EfiBootServicesCode   0x0008
+  #  EfiBootServicesData   0x0010
+  #  EfiRuntimeServicesCode0x0020
+  #  EfiRuntimeServicesData0x0040
+  #  EfiConventionalMemory 0x0080
+  #  EfiUnusableMemory 0x0100
+  #  EfiACPIReclaimMemory  0x0200
+  #  EfiACPIMemoryNVS  0x0400
+  #  EfiMemoryMappedIO 0x0800
+  #  EfiMemoryMappedIOPortSpace0x1000
+  #  EfiPalCode0x2000
+  #  EfiPersistentMemory   0x4000
+  #  OEM Reserved  0x4000
+  #  OS Reserved   0x8000
+  # e.g. LoaderCode+LoaderData+BootServicesCode+BootServicesData are needed, 
0x1E should be used.
+  # @Prompt The memory type mask for Pool Guard.
+  gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType|0x0|UINT64|0x30001052
+
+  ## This mask is to control Heap Guard behavior.
+  #   BIT0 - Enable UEFI page guard.
+  #   BIT1 - Enable UEFI pool guard.
+  #   BIT2 - Enable SMM page guard.
+  #   BIT3 - Enable SMM pool guard.
+  #   BIT7 - The direction of Guard Page for Pool Guard.
+  #  0 - The returned pool is adjacent to the bottom guard page.
+  #  1 - The returned pool is adjacent to the top guard page.
+  # @Prompt The Heap Guard feature mask
+  gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask|0x0|UINT8|0x30001053
+
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   ## Dynamic type PCD can be registered callback function for Pcd setting 
action.
   #  PcdMaxPeiPcdCallBackNumberPerPcdEntry indicates the maximum number of 
callback function
diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni
index d6015de75f..74c27039bf 100644
--- a/MdeModulePkg/MdeModulePkg.uni
+++ b/MdeModulePkg/MdeModulePkg.uni
@@ -1127,3 +1127,61 @@

  "enabled on AMD processors supporting the Secure 
Encrypted Virtualization (SEV) feature.\n"

  "This mask should be applied when creating 1:1 virtual to 
physical mapping tables."
 
+#string 

[edk2] [PATCH 0/5] Implement heap guard feature

[Jian J Wang]

This feature makes use of paging mechanism to add a hidden (not present)
page just before and after the allocated memory block. If the code tries
to access memory outside of the allocated part, page fault exception will
be triggered.

This feature is disabled by default and is not recommended to enable it
in production build of BIOS.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 

Jian J Wang (5):
  MdeModulePkg/DxeCore: Implement heap guard feature for UEFI
  MdeModulePkg/PiSmmCore: Implement heap guard feature for SMM mode
  MdeModulePkg/MdeModulePkg.dec,.uni: Add heap guard related PCDs and
string tokens
  UefiCpuPkg/CpuDxe: Reduce debug message
  UefiCpuPkg/PiSmmCpuDxeSmm: Disable page table protection

 MdeModulePkg/Core/Dxe/DxeMain.inf|4 +
 MdeModulePkg/Core/Dxe/Mem/HeapGuard.c| 1171 +
 MdeModulePkg/Core/Dxe/Mem/HeapGuard.h|  391 +++
 MdeModulePkg/Core/Dxe/Mem/Imem.h |   38 +-
 MdeModulePkg/Core/Dxe/Mem/Page.c |  129 ++-
 MdeModulePkg/Core/Dxe/Mem/Pool.c |  154 ++-
 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c | 1438 ++
 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.h |  395 +++
 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.c |  704 +
 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.h |  174 
 MdeModulePkg/Core/PiSmmCore/Page.c   |   51 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c  |   12 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h  |   80 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf|8 +
 MdeModulePkg/Core/PiSmmCore/Pool.c   |   77 +-
 MdeModulePkg/MdeModulePkg.dec|   57 +
 MdeModulePkg/MdeModulePkg.uni|   58 ++
 UefiCpuPkg/CpuDxe/CpuPageTable.c |5 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |1 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  |2 +-
 20 files changed, 4854 insertions(+), 95 deletions(-)
 create mode 100644 MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
 create mode 100644 MdeModulePkg/Core/Dxe/Mem/HeapGuard.h
 create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c
 create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.h
 create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.c
 create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.h

-- 
2.14.1.windows.1

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

[edk2] [PATCH 2/5] MdeModulePkg/PiSmmCore: Implement heap guard feature for SMM mode

[Jian J Wang]

This feature makes use of paging mechanism to add a hidden (not present)
page just before and after the allocated memory block. If the code tries
to access memory outside of the allocated part, page fault exception will
be triggered.

This feature is controlled by three PCDs:

gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPageType

BIT2 and BIT3 of PcdHeapGuardPropertyMask can be used to enable or disable
memory guard for SMM page and pool respectively. PcdHeapGuardPoolType and/or
PcdHeapGuardPageType are used to enable or disable guard for specific type
of memory. For example, we can turn on guard only for EfiBootServicesData
and EfiRuntimeServicesData by setting the PCD with value 0x50.

Pool memory is not ususally integer multiple of one page, and is more likely
less than a page. There's no way to monitor the overflow at both top and
bottom of pool memory. BIT7 of PcdHeapGuardPropertyMask is used to control
how to position the head of pool memory so that it's easier to catch memory
overflow in memory growing direction or in decreasing direction.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c | 1438 ++
 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.h |  395 +++
 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.c |  704 +
 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.h |  174 
 MdeModulePkg/Core/PiSmmCore/Page.c   |   51 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c  |   12 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h  |   80 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf|8 +
 MdeModulePkg/Core/PiSmmCore/Pool.c   |   77 +-
 9 files changed, 2911 insertions(+), 28 deletions(-)
 create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c
 create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.h
 create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.c
 create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.h

diff --git a/MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c 
b/MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c
new file mode 100644
index 00..c64eaea5d1
--- /dev/null
+++ b/MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c
@@ -0,0 +1,1438 @@
+/** @file
+  UEFI Heap Guard functions.
+
+Copyright (c) 2017, Intel Corporation. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include "HeapGuard.h"
+
+//
+// Pointer to table tracking the Guarded memory with bitmap, in which  '1'
+// is used to indicate memory guarded. '0' might be free memory or Guard
+// page itself, depending on status of memory adjacent to it.
+//
+GLOBAL_REMOVE_IF_UNREFERENCED UINT64 *mGuardedMemoryMap = NULL;
+
+//
+// Current depth level of map table pointed by mGuardedMemoryMap.
+// mMapLevel must be initialized at least by 1. It will be automatically
+// updated according to the address of memory just tracked.
+//
+GLOBAL_REMOVE_IF_UNREFERENCED UINTN  mMapLevel = 1;
+
+//
+// SMM status flag
+//
+BOOLEAN mIsSmmCpuMode = FALSE;
+
+/**
+  Set corresponding bits in bitmap table to 1 according to the address
+
+  @param[in]  Address Start address to set for
+  @param[in]  BitNumber   Number of bits to set
+  @param[in]  BitMap  Pointer to bitmap which covers the Address
+
+  @return VOID
+**/
+STATIC
+VOID
+SetBits (
+  IN EFI_PHYSICAL_ADDRESSAddress,
+  IN UINTN   BitNumber,
+  IN UINT64  *BitMap
+  )
+{
+  UINTN   Lsbs;
+  UINTN   Qwords;
+  UINTN   Msbs;
+  UINTN   StartBit;
+  UINTN   EndBit;
+
+  StartBit  = (UINTN)GUARDED_HEAP_MAP_ENTRY_BIT_INDEX (Address);
+  EndBit= (StartBit + BitNumber - 1) % GUARDED_HEAP_MAP_ENTRY_BITS;
+
+  if ((StartBit + BitNumber) > GUARDED_HEAP_MAP_ENTRY_BITS) {
+Msbs= (GUARDED_HEAP_MAP_ENTRY_BITS - StartBit) %
+  GUARDED_HEAP_MAP_ENTRY_BITS;
+Lsbs= (EndBit + 1) % GUARDED_HEAP_MAP_ENTRY_BITS;
+Qwords  = (BitNumber - Msbs) / GUARDED_HEAP_MAP_ENTRY_BITS;
+  } else {
+Msbs= BitNumber;
+Lsbs= 0;
+Qwords  = 0;
+  }
+
+  if (Msbs > 0) {
+*BitMap |= LShiftU64 (LShiftU64 (1, Msbs) - 1, StartBit);
+BitMap  += 1;
+  }

[edk2] [PATCH 1/5] MdeModulePkg/DxeCore: Implement heap guard feature for UEFI

[Jian J Wang]

This feature makes use of paging mechanism to add a hidden (not present)
page just before and after the allocated memory block. If the code tries
to access memory outside of the allocated part, page fault exception will
be triggered.

This feature is controlled by three PCDs:

gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPageType

BIT0 and BIT1 of PcdHeapGuardPropertyMask can be used to enable or disable
memory guard for page and pool respectively. PcdHeapGuardPoolType and/or
PcdHeapGuardPageType are used to enable or disable guard for specific type
of memory. For example, we can turn on guard only for EfiBootServicesData
and EfiRuntimeServicesData by setting the PCD with value 0x50.

Pool memory is not ususally integer multiple of one page, and is more likely
less than a page. There's no way to monitor the overflow at both top and
bottom of pool memory. BIT7 of PcdHeapGuardPropertyMask is used to control
how to position the head of pool memory so that it's easier to catch memory
overflow in memory growing direction or in decreasing direction.

Note: Turning on heap guard, especially pool guard, will introduce too many
memory fragments. Windows 10 has a limitation in its boot loader, which
accepts at most 512 memory descriptors passed from BIOS. This will prevent
Windows 10 from booting if heap guard is enabled. The latest Linux
distribution with grub boot loader has no such issue. Normally it's not
recommended to enable this feature in production build of BIOS.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/DxeMain.inf |4 +
 MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 1171 +
 MdeModulePkg/Core/Dxe/Mem/HeapGuard.h |  391 +++
 MdeModulePkg/Core/Dxe/Mem/Imem.h  |   38 +-
 MdeModulePkg/Core/Dxe/Mem/Page.c  |  129 +++-
 MdeModulePkg/Core/Dxe/Mem/Pool.c  |  154 -
 6 files changed, 1823 insertions(+), 64 deletions(-)
 create mode 100644 MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
 create mode 100644 MdeModulePkg/Core/Dxe/Mem/HeapGuard.h

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
b/MdeModulePkg/Core/Dxe/DxeMain.inf
index e29d6c83ae..6b27714a79 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -56,6 +56,7 @@
   Mem/MemData.c
   Mem/Imem.h
   Mem/MemoryProfileRecord.c
+  Mem/HeapGuard.c
   FwVolBlock/FwVolBlock.c
   FwVolBlock/FwVolBlock.h
   FwVol/FwVolWrite.c
@@ -192,6 +193,9 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPageType   ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType   ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask   ## 
CONSUMES
 
 # [Hob]
 # RESOURCE_DESCRIPTOR   ## CONSUMES
diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c 
b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
new file mode 100644
index 00..36e41d9a87
--- /dev/null
+++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
@@ -0,0 +1,1171 @@
+/** @file
+  UEFI Heap Guard functions.
+
+Copyright (c) 2017, Intel Corporation. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include "DxeMain.h"
+#include "Imem.h"
+#include "HeapGuard.h"
+
+//
+// Global to avoid infinite reentrance of memory allocation when updating
+// page table attributes, which may need allocate pages for new PDE/PTE.
+//
+GLOBAL_REMOVE_IF_UNREFERENCED BOOLEAN mOnGuarding = FALSE;
+
+//
+// Pointer to table tracking the Guarded memory with bitmap, in which  '1'
+// is used to indicate memory guarded. '0' might be free memory or Guard
+// page itself, depending on status of memory adjacent to it.
+//
+GLOBAL_REMOVE_IF_UNREFERENCED UINT64 *mGuardedMemoryMap = NULL;
+
+//
+// Current depth level of map table pointed by mGuardedMemoryMap.
+// mMapLevel must be initialized at least by 1. It will be automatically
+// updated according to the address of memory just tracked.
+//

[edk2] Plan to remove ifconfig6/ping6 in NetworkPkg

[Fu, Siyuan]

Hi, All

Edk2 has duplicated ping6/ifconfig6 implementation in NetworkPkg and ShellPkg, 
we have plan to remove (delete) those applications in NetworkPkg. Please let me 
know if you have any concern about this.

File to remove:
NetworkPkg\Application\IfConfig6\*

 NetworkPkg\Application\Ping6\*
Actively maintained in future:

ShellPkg\Library\UefiShellNetwork2CommandsLib\Ifconfig6.c

  ShellPkg\Library\UefiShellNetwork2CommandsLib\Ping6.c

The usage and parameter format of these 2 versions are exactly same. The code 
in ShellPkg is actively maintained now, some bug fixes were only applied to the 
ShellPkg version in the past year. Users should use the standard version in 
ShellPkg in future.

I will send out patch to remove the IfConfig6 and Ping6 applications in 
NetworkPkg in next few days if no object to this email.

BestRegards
Fu Siyuan

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

[edk2] [Patch 3/3] MdeModulePkg/PiSmmCore: Install Protocol when S3 resume finished.

[Eric Dong]

Install EdkiiSmmEndOfS3ResumeProtocol when S3 resume finished.
S3ResumePei will send S3 resume finished event to SmmCore through
communication buffer.

Cc: Ruiyu Ni 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c   | 55 +++
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h   | 24 ++
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf |  1 +
 3 files changed, 73 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
index 9e4390e..aa44933 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
@@ -75,13 +75,14 @@ BOOLEAN  mInLegacyBoot = FALSE;
 // Table of SMI Handlers that are registered by the SMM Core when it is 
initialized
 //
 SMM_CORE_SMI_HANDLERS  mSmmCoreSmiHandlers[] = {
-  { SmmDriverDispatchHandler,   ,  NULL, TRUE 
 },
-  { SmmReadyToLockHandler,  , NULL, TRUE 
}, 
-  { SmmLegacyBootHandler,   ,   NULL, 
FALSE },
-  { SmmExitBootServicesHandler, , NULL, 
FALSE },
-  { SmmReadyToBootHandler,  ,  NULL, 
FALSE },
-  { SmmEndOfDxeHandler, ,NULL, TRUE 
},
-  { NULL,   NULL,   NULL, 
FALSE }
+  { SmmDriverDispatchHandler,   ,   NULL, 
TRUE  },
+  { SmmReadyToLockHandler,  ,  NULL, 
TRUE }, 
+  { SmmLegacyBootHandler,   ,NULL, 
FALSE },
+  { SmmExitBootServicesHandler, ,  NULL, 
FALSE },
+  { SmmReadyToBootHandler,  ,   NULL, 
FALSE },
+  { SmmEndOfDxeHandler, , NULL, 
TRUE },
+  { SmmEndOfS3ResumeHandler,, NULL, 
FALSE },
+  { NULL,   NULL,NULL, 
FALSE }
 };
 
 UINTN   mFullSmramRangeCount;
@@ -383,6 +384,46 @@ SmmEndOfDxeHandler (
 }
 
 /**
+  Software SMI handler that is called when the EndOfS3Resume event is trigged.
+  This function installs the SMM EndOfS3Resume Protocol so SMM Drivers are 
informed that
+  S3 resume has finished.
+
+  @param  DispatchHandle  The unique handle assigned to this handler by 
SmiHandlerRegister().
+  @param  Context Points to an optional handler context which was 
specified when the handler was registered.
+  @param  CommBuffer  A pointer to a collection of data in memory that will
+  be conveyed from a non-SMM environment into an SMM 
environment.
+  @param  CommBufferSize  The size of the CommBuffer.
+
+  @return Status Code
+
+**/
+EFI_STATUS
+EFIAPI
+SmmEndOfS3ResumeHandler (
+  IN EFI_HANDLE  DispatchHandle,
+  IN CONST VOID  *Context,OPTIONAL
+  IN OUT VOID*CommBuffer, OPTIONAL
+  IN OUT UINTN   *CommBufferSize  OPTIONAL
+  )
+{
+  EFI_STATUS  Status;
+  EFI_HANDLE  SmmHandle;
+
+  DEBUG ((EFI_D_INFO, "SmmEndOfS3ResumeHandler\n"));
+  //
+  // Install SMM EndOfDxe protocol
+  //
+  SmmHandle = NULL;
+  Status = SmmInstallProtocolInterface (
+ ,
+ ,
+ EFI_NATIVE_INTERFACE,
+ NULL
+ );
+  return Status;
+}
+
+/**
   Determine if two buffers overlap in memory.
 
   @param[in] Buff1  Pointer to first buffer
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
index b6f815c..6cc824b 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -802,6 +803,29 @@ SmmReadyToBootHandler (
   );
 
 /**
+  Software SMI handler that is called when the EndOfS3Resume event is trigged.
+  This function installs the SMM EndOfS3Resume Protocol so SMM Drivers are 
informed that
+  S3 resume has finished.
+
+  @param  DispatchHandle  The unique handle assigned to this handler by 
SmiHandlerRegister().
+  @param  Context Points to an optional handler context which was 
specified when the handler was registered.
+  @param  CommBuffer  A pointer to a collection of data in memory that will
+  be conveyed from a non-SMM environment into an SMM 
environment.
+  @param  CommBufferSize  The size of the CommBuffer.
+
+  @return Status Code
+
+**/
+EFI_STATUS
+EFIAPI
+SmmEndOfS3ResumeHandler (
+  IN EFI_HANDLE  DispatchHandle,
+  IN CONST VOID  *Context,OPTIONAL
+  IN OUT VOID*CommBuffer, OPTIONAL
+  IN OUT UINTN   *CommBufferSize  OPTIONAL
+  );
+
+/**
   Place holder function until all the SMM System Table Service are available.
 
   @param  Arg1   Undefined
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
index 95e34bd..a724189 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf

[edk2] [Patch 0/3] Add SmmEndOfS3Resume event.

[Eric Dong]

This patch series add new SmmEndOfS3Resume event which required by some
SMM drivers. 
It will implmented by SmmCore to install the gEdkiiSmmEndOfS3ResumeProtocolGuid
Protocol. Smm drivers can install this protocol's notification functions to 
hoot this envet.
It will be trigged right after the EndOfPei event in S3 resume phase.

Cc: Ruiyu Ni 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 

Eric Dong (3):
  MdeModulePkg/SmmEndOfS3Resume.h: Add new protocol definition.
  UefiCpuPkg/S3Resume2Pei: Send S3 resume finished event to SmmCore.
  MdeModulePkg/PiSmmCore: Install Protocol when S3 resume finished.

 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c| 55 --
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h| 24 ++
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf  |  1 +
 MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h   | 31 
 MdeModulePkg/MdeModulePkg.dec  |  3 +
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c  | 85 ++
 .../Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf   |  4 +
 7 files changed, 196 insertions(+), 7 deletions(-)
 create mode 100644 MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h

-- 
2.7.0.windows.1

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

[edk2] [Patch 1/3] MdeModulePkg/SmmEndOfS3Resume.h: Add new protocol definition.

[Eric Dong]

Add gEdkiiSmmEndOfS3ResumeProtocolGuid which used by SmmCore to
notify smm drives that S3 resume has finished.

Cc: Ruiyu Ni 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h | 26 
 MdeModulePkg/MdeModulePkg.dec|  3 +++
 2 files changed, 29 insertions(+)
 create mode 100644 MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h

diff --git a/MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h 
b/MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h
new file mode 100644
index 000..9716f6a
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/SmmEndOfS3Resume.h
@@ -0,0 +1,26 @@
+/** @file
+  This Protocol will be installed at the end of S3 resume phase in SMM 
environment. 
+  It allows for smm drivers to hook this point and do the requried tasks.
+
+  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  This program and the accompanying materials  
+  are licensed and made available under the terms and conditions of the BSD 
License 
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php   
 
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
 
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED. 
+
+**/
+
+#ifndef __SMM_END_OF_S3_RESUME_H__
+#define __SMM_END_OF_S3_RESUME_H__
+
+#define EDKII_SMM_END_OF_S3_RESUME_PROTOCOL_GUID \
+  { \
+0x96f5296d, 0x05f7, 0x4f3c, {0x84, 0x67, 0xe4, 0x56, 0x89, 0x0e, 0x0c, 
0xb5 } \
+  }
+
+extern EFI_GUID gEdkiiSmmEndOfS3ResumeProtocolGuid;
+
+#endif
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index a3c0633..216e4f9 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -556,6 +556,9 @@
   ## Include/Protocol/IoMmu.h
   gEdkiiIoMmuProtocolGuid = { 0x4e939de9, 0xd948, 0x4b0f, { 0x88, 0xed, 0xe6, 
0xe1, 0xce, 0x51, 0x7c, 0x1e } }
 
+  ## Include/Protocol/SmmEndofS3Resume.h
+  gEdkiiSmmEndOfS3ResumeProtocolGuid = { 0x96f5296d, 0x05f7, 0x4f3c, {0x84, 
0x67, 0xe4, 0x56, 0x89, 0x0e, 0x0c, 0xb5 } }
+
 #
 # [Error.gEfiMdeModulePkgTokenSpaceGuid]
 #   0x8001 | Invalid value provided.
-- 
2.7.0.windows.1

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

[edk2] [Patch 2/3] UefiCpuPkg/S3Resume2Pei: Send S3 resume finished event to SmmCore.

[Eric Dong]

Driver will send S3 resume finished event to SmmCore through communicate
buffer after it signals EndOfPei event.

Cc: Ruiyu Ni 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c  | 85 ++
 .../Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf   |  4 +
 2 files changed, 89 insertions(+)

diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index e53ed21..8350eb9 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
@@ -28,6 +28,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include 
 
 #include 
 #include 
@@ -151,6 +154,23 @@ typedef union {
   UINT64Uint64;
 } PAGE_TABLE_1G_ENTRY;
 
+//
+// Define two type of smm communicate headers.
+// One for 32 bits  PEI + 64 bits DXE, the other for 32 bits PEI + 32 bits DXE 
case.
+//
+typedef struct {
+
+  EFI_GUID  HeaderGuid;
+  UINT32MessageLength;
+  UINT8 Data[1];
+} EFI_SMM_COMMUNICATE_HEADER_IA32;
+
+typedef struct {
+  EFI_GUID  HeaderGuid;
+  UINT64MessageLength;
+  UINT8 Data[1];
+} EFI_SMM_COMMUNICATE_HEADER_IA64;
+
 #pragma pack()
 
 //
@@ -430,6 +450,65 @@ IsLongModeWakingVector (
 }
 
 /**
+  Send EndOfS3Resume event to SmmCore through communication buffer way.
+
+  @retval  EFI_SUCCESS Return send the event success.
+**/
+EFI_STATUS
+SignalEndOfS3Resume (
+  VOID
+  )
+{
+  EFI_STATUS Status;
+  EFI_PEI_SMM_COMMUNICATION_PPI  *SmmCommunicationPpi;
+  UINTN  CommSize;
+  EFI_SMM_COMMUNICATE_HEADER_IA32Header32;
+  EFI_SMM_COMMUNICATE_HEADER_IA64Header64;
+  VOID   *CommBuffer;
+
+  DEBUG ((EFI_D_INFO, "SignalEndOfS3Resume - Enter\n"));
+
+  //
+  // Detect whether current is 32 bits PEI + 64 bits DXE case.
+  //
+  if ((sizeof(UINTN) == sizeof(UINT32)) && (FeaturePcdGet 
(PcdDxeIplSwitchToLongMode))) {
+CommBuffer = 
+Header64.MessageLength = 0;
+CommSize = sizeof (EFI_SMM_COMMUNICATE_HEADER_IA64);
+  } else {
+CommBuffer = 
+Header32.MessageLength = 0;
+CommSize = sizeof (EFI_SMM_COMMUNICATE_HEADER_IA32);
+  }
+  CopyGuid (CommBuffer, );
+
+  //
+  // Get needed resource
+  //
+  Status = PeiServicesLocatePpi (
+ ,
+ 0,
+ NULL,
+ (VOID **)
+ );
+  ASSERT_EFI_ERROR (Status);
+
+  //
+  // Send command
+  //
+  Status = SmmCommunicationPpi->Communicate (
+  SmmCommunicationPpi,
+  (VOID *)CommBuffer,
+  
+  );
+  ASSERT_EFI_ERROR (Status);
+
+  DEBUG ((EFI_D_INFO, "SignalEndOfS3Resume - Exit (%r)\n", Status));
+
+  return Status;
+}
+
+/**
   Jump to OS waking vector.
   The function will install boot script done PPI, report S3 resume status 
code, and then jump to OS waking vector.
 
@@ -504,6 +583,12 @@ S3ResumeBootOs (
   ASSERT_EFI_ERROR (Status);
 
   //
+  // Signal EndOfS3Resume event.
+  //
+  Status = SignalEndOfS3Resume ();
+  ASSERT_EFI_ERROR (Status);
+
+  //
   // report status code on S3 resume
   //
   REPORT_STATUS_CODE (EFI_PROGRESS_CODE, EFI_SOFTWARE_PEI_MODULE | 
EFI_SW_PEI_PC_OS_WAKE);
diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
index d514523..943f114 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
@@ -85,6 +85,10 @@
   gPeiSmmAccessPpiGuid  ## SOMETIMES_CONSUMES
   gPeiPostScriptTablePpiGuid## SOMETIMES_PRODUCES
   gEfiEndOfPeiSignalPpiGuid ## SOMETIMES_PRODUCES
+  gEfiPeiSmmCommunicationPpiGuid## SOMETIMES_CONSUMES
+
+[Protocols]
+  gEdkiiSmmEndOfS3ResumeProtocolGuid## SOMETIMES_CONSUMES
 
 [FeaturePcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode ## CONSUMES
-- 
2.7.0.windows.1

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

Re: [edk2] [PATCH] SecurityPkg\Tcg2Pei: FV measure performance enhancement

[Long, Qin]

Reviewed-by: Long Qin 


Best Regards & Thanks,
LONG, Qin

-Original Message-
From: Zhang, Chao B 
Sent: Monday, October 9, 2017 4:50 PM
To: edk2-devel@lists.01.org
Cc: Long, Qin ; Yao, Jiewen ; 
sean.bro...@microsoft.com; Zhang, Chao B 
Subject: [PATCH] SecurityPkg\Tcg2Pei: FV measure performance enhancement

1. Leverage Pre-Hashed FV PPI to reduce duplicated hash 2. Only measure BFV at 
the beginning. Other FVs are measured in FVinfo callback with nested
   FV check. https://bugzilla.tianocore.org/show_bug.cgi?id=662

Cc: Long Qin 
Cc: Yao Jiewen 
Cc: Sean Brogan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
---
 .../Include/Ppi/FirmwareVolumeInfoPrehashedFV.h|  70 ++
 SecurityPkg/SecurityPkg.dec|   7 +-
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c  | 245 +++--
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf|   2 +
 4 files changed, 250 insertions(+), 74 deletions(-)  create mode 100644 
SecurityPkg/Include/Ppi/FirmwareVolumeInfoPrehashedFV.h

diff --git a/SecurityPkg/Include/Ppi/FirmwareVolumeInfoPrehashedFV.h 
b/SecurityPkg/Include/Ppi/FirmwareVolumeInfoPrehashedFV.h
new file mode 100644
index 000..2273357
--- /dev/null
+++ b/SecurityPkg/Include/Ppi/FirmwareVolumeInfoPrehashedFV.h
@@ -0,0 +1,70 @@
+/** @file
+PPI to describe all hash digests for a given FV
+
+Copyright (c) 2017, Intel Corporation. All rights reserved. This 
+program and the accompanying materials are licensed and made available 
+under the terms and conditions of the BSD License which accompanies 
+this distribution.  The full text of the license may be found at 
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+/**
+PPI to describe all hash digests for a given FV
+
+Copyright (c) 2017, Microsoft Corporation
+
+All rights reserved.
+Redistribution and use in source and binary forms, with or without 
+modification, are permitted provided that the following conditions are met:
+1. Redistributions of source code must retain the above copyright 
+notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright 
+notice, this list of conditions and the following disclaimer in the 
+documentation  and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
+IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED 
+TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
PURPOSE ARE DISCLAIMED.
+IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR 
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 
+STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING 
+IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY 
OF SUCH DAMAGE.
+
+**/
+
+#ifndef __PEI_FIRMWARE_VOLUME_INFO_PREHASHED_FV_H__
+#define __PEI_FIRMWARE_VOLUME_INFO_PREHASHED_FV_H__
+
+#define EDKII_PEI_FIRMWARE_VOLUME_INFO_PREHASHED_FV_PPI_GUID \  { 
+0x3ce1e631, 0x7008, 0x477c, { 0xad, 0xa7, 0x5d, 0xcf, 0xc7, 0xc1, 0x49, 
+0x4b } }
+
+//
+// HashAlgoId is TPM_ALG_ID in Tpm20.h
+//
+typedef struct _HASH_INFO {
+  UINT16 HashAlgoId;
+  UINT16 HashSize;
+  //UINT8Hash[];
+} HASH_INFO;
+
+//
+// This PPI indicates a FV is already hashed, platform should ensure 1:1 
mapping between pre-hashed PPI and FV.
+// The Count field in PPI is followed by Count number of FV hash info entries, 
which can be extended to PCR and logged to TCG event log directly by TCG 
modules.
+//
+typedef struct {
+  UINT32 FvBase;
+  UINT32 FvLength;
+  UINT32 Count;
+  //HASH_INFOHashInfo[];
+} EDKII_PEI_FIRMWARE_VOLUME_INFO_PREHASHED_FV_PPI;
+
+extern EFI_GUID gEdkiiPeiFirmwareVolumeInfoPrehashedFvPpiGuid;
+
+#endif
+
diff --git a/SecurityPkg/SecurityPkg.dec b/SecurityPkg/SecurityPkg.dec index 
7a900dc..45d95c5 100644
--- a/SecurityPkg/SecurityPkg.dec
+++ b/SecurityPkg/SecurityPkg.dec
@@ -7,6 +7,7 @@
 #
 # Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.  # 
(C) Copyright 2015 Hewlett Packard Enterprise Development LP 
+# Copyright (c) 2017, Microsoft 

Re: [edk2] [PATCH 0/2] Dynamic Tables

[Yao, Jiewen]

Thank you!

Comment in line.


From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Evan 
Lloyd
Sent: Wednesday, October 11, 2017 2:52 AM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com; 
"ard.biesheu...@linaro.org"@arm.com; "stephanie.hughes-f...@arm.com"@arm.com; 
"thomas.abra...@arm.com"@arm.com; "arvind.chau...@arm.com"@arm.com; 
"leif.lindh...@linaro.org"@arm.com; "daniil.egra...@arm.com"@arm.com
Subject: Re: [edk2] [PATCH 0/2] Dynamic Tables

Hi Jiewen
(I hope that is your personal name, not your surname - but it is a bit hard for 
us barbarians to tell, sorry.)

[Jiewen] Ah sorry about that. You are right. Jiewen is my given name. ☺

Thank you for the very helpful feedback.
Responses are inline below.

> -Original Message-
> From: Yao, Jiewen [mailto:jiewen@intel.com]
> Sent: 10 October 2017 03:29
> To: Evan Lloyd >; 
> edk2-devel@lists.01.org
> Cc: 
> "matteo.carl...@arm.com"@arm.com;
>  "n...@arm.com"@arm.com;
> "ard.biesheu...@linaro.org"@arm.com;
>  "Stephanie.Hughes-
> f...@arm.com"@arm.com; 
> "thomas.abra...@arm.com"@arm.com;
> "arvind.chau...@arm.com"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "daniil.egra...@arm.com"@arm.com;
>  Yao, Jiewen >
> Subject: RE: [edk2] [PATCH 0/2] Dynamic Tables
>
> HI Evan
> Thanks for the contribution.
>
> This is a very big feature. It may talk us more time to review and evaluate.
> At same time, one of our key MdeModule package maintainer is in paternity
> leave. It may be longer than usual.
>
> I notice you only defined ARM namespace in this patch, and implemented
> ARM library instance.
> Also most consumers of ConfigurationManager are from ARM platform
> package. So if it urgent from ARM platform, you may consider to check into
> ArmPkg at first.

[[Evan Lloyd]] This sounds sensible, and I will discuss it with Leif.  Another 
option might be to start up a new module.

[Jiewen] Right. I also replied mail from Sean Brogan (MSFT), who has concern on 
putting this to MdeModulePkg. But the mail was so long that it was filtered 
before.
If ArmPkg can be the first landing zone, that is great.

>
>
>
> I only have a quick look at the patch. Would you please share more on the
> design philosophy?

[[Evan Lloyd]] You are quite right - we will put a document together on this.

>
> 1) It seems the final goal is still to generate ACPI table/SMBIOS 
> table/DevTree.
> You just introduce a way to manage how these tables are generated, right?

[[Evan Lloyd]] Yes.

>
> 2) Below definition is defined by the
> MdeModulePkg/Include/DynamicTables/ConfigurationManagerObject.h.
> Is there any industry standard to define below index? Or it is just defined by
> EDKII, and anyone can add extension here?

[[Evan Lloyd]] This is an initial submission for discussion, but there is not 
currently a relevant standard.  We are providing a "proof of concept" for 
discussion and review.  The ids are currently internal to edk2.  We do 
anticipate some sort of standard definition (for the information supplier) but 
that might be no more than a version of ConfigurationManagerObject.h

>
> +Object ID's in the ARM Namespace:
> +   0 - Reserved
> +   1 - Boot Architecture Info
> +   2 - CPU Info
> +   3 - Power Management Profile Info
> +   4 - GICC Info
> +   5 - GICD Info
> +   6 - GIC MSI Frame Info
> +   7 - GIC Redistributor Info
> +   8 - GIC ITS Info
> +   9 - Serial Console Port Info
> +  10 - Serial Debug Port Info
> +  12 - Generic Timer Info
> +  13 - Platform GT Block Info
> +  14 - Platform Generic Watchdog
> +  15 - PCI Configuration Space Info
> +  16 - Hypervisor Vendor Id
>
> 3) I am not sure if you have known about datahub protocol.
> (IntelFrameworkPkg\Include\Protocol\DataHub.h)

[[Evan Lloyd]] We did not.  We have not previously paid much attention to 
IntelFrameworkPkg  
We will have a look at the DataHub stuff though, to see how it fits.

> Long time ago, we have platform module filling the SMBIOS needed
> information to datahub (such as CPU INFO, Memory Info).
> The SMBIOS table is derived from datahub protocol. The setup driver can
> also from datahub.
> But later, we think it is an overdesign and datahub is no longer used in the
> new IA platform.
> People feel it is easier to fill industry defined SMBIOS record directly, 
> than to
> fill the EDK defined datahub record.
> They do not need to learn 2 different styles of data record format.
>
> To me, this seems similar to datahub. Please 

Re: [edk2] [PATCH v4 0/6] Add NULL pointer detection feature

[Wang, Jian J]

Hi,

Any more comments for this version of patch? If no, I'll check in it today. 
Thanks.

Jian

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Monday, October 09, 2017 10:17 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH v4 0/6] Add NULL pointer detection feature
> 
> The mechanism behind is to trigger a page fault exception at address 0.
> This can be made by disabling page 0 (0-4095) during page table setup.
> So this feature can only be available on platform with paging enabled.
> 
> Once this feature is enabled, any code, like CSM, which has to access
> memory in page 0 needs to enable this page temporarily in advance and
> disable it afterwards.
> 
> PcdNullPointerDetectionPropertyMask is used to control and elaborate
> the use cases. For example, BIT7 of this PCD must be set for Windows 7
> boot on Qemu if BIT0 set; or boot will fail.
> 
> Suggested-by: Ayellet Wolman 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> 
> Jian J Wang (5):
>   MdeModulePkg/DxeIpl: Implement NULL pointer detection
>   MdeModulePkg/Core/Dxe: Add EndOfDxe workaround for NULL pointer
> detection
>   UefiCpuPkg/PiSmmCpuDxeSmm: Implement NULL pointer detection for SMM
> code
>   IntelFrameworkModulePkg/Csm: Add code to bypass NULL pointer detection
>   OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM
> installing
> 
> Wang, Jian J (1):
>   MdeModulePkg/MdeModulePkg.dec,.uni: Add NULL pointer detection PCD
> 
>  .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c   | 101 ++
>  .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h   |   2 +
>  .../Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf  |   2 +
>  .../Csm/LegacyBiosDxe/LegacyBda.c  |   4 +
>  .../Csm/LegacyBiosDxe/LegacyBios.c | 152 
> +
>  .../Csm/LegacyBiosDxe/LegacyBiosDxe.inf|   2 +
>  .../Csm/LegacyBiosDxe/LegacyBiosInterface.h|  18 +++
>  .../Csm/LegacyBiosDxe/LegacyBootSupport.c  |  23 +++-
>  .../Csm/LegacyBiosDxe/LegacyPci.c  |  17 ++-
>  IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c  |  27 +++-
>  MdeModulePkg/Core/Dxe/DxeMain.inf  |   1 +
>  MdeModulePkg/Core/Dxe/Mem/Page.c   |   4 +-
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c  |  65 +
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h  |  25 
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   1 +
>  MdeModulePkg/Core/DxeIplPeim/DxeLoad.c |   1 +
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|  17 ++-
>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c |   4 +
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   |  93 -
>  MdeModulePkg/MdeModulePkg.dec  |  13 ++
>  MdeModulePkg/MdeModulePkg.uni  |  13 ++
>  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |   1 +
>  OvmfPkg/QemuVideoDxe/VbeShim.c |  14 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |  12 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  |  25 +++-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |   1 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c|  12 ++
>  27 files changed, 628 insertions(+), 22 deletions(-)
> 
> --
> 2.14.1.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 v4] Ifconfig : Fixed False information about Media State.

[Wu, Jiaxin]

Reviewed-by: Wu Jiaxin 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Meenakshi Aggarwal
> Sent: Tuesday, October 10, 2017 10:08 PM
> To: edk2-devel@lists.01.org; Wu, Jiaxin ; Carsey,
> Jaben ; Ni, Ruiyu 
> Subject: [edk2] [PATCH v4] Ifconfig : Fixed False information about Media
> State.
> 
> Issue : We were setting MediaPresent as TRUE (default) and
> not checking return status of NetLibDetectMedia().
> NetLibDetectMedia() sets MediaPresent FLAG in case of success
> only and dont change flag on error.
> So, Media State will display as 'Media Present', in case of
> error also.
> 
> Fix : Check return value of NetLibDetectMedia(), if error then
> print "Media State Unknown"
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> 
> Signed-off-by: Meenakshi Aggarwal 
> ---
>  ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c | 11 +++--
> --
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> index 4db07b2..082ab72 100644
> --- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> +++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> @@ -576,11 +576,14 @@ IfConfigShowInterfaceInfo (
>  //
>  // Get Media State.
>  //
> -NetLibDetectMedia (IfCb->NicHandle, );
> -if (!MediaPresent) {
> -  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> (STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle, L"Media
> disconnected");
> +if (EFI_SUCCESS == NetLibDetectMedia (IfCb->NicHandle,
> )) {
> +  if (!MediaPresent) {
> +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> (STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle, L"Media
> disconnected");
> +  } else {
> +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> (STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle, L"Media
> present");
> +  }
>  } else {
> -  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> (STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle, L"Media
> present");
> +  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> (STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle, L"Media
> state unknown");
>  }
> 
>  //
> --
> 2.7.4
> 
> ___
> 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] [platforms: PATCH 08/13] Marvell/Armada: Modify GICC alias

[Leif Lindholm]

On Tue, Oct 10, 2017 at 09:45:29PM +0100, Ard Biesheuvel wrote:
> On 10 October 2017 at 15:56, Marcin Wojtas  wrote:
> > Hi Ard,
> >
> > 2017-10-10 16:53 GMT+02:00 Leif Lindholm :
> >> On Mon, Oct 09, 2017 at 07:00:57PM +0200, Marcin Wojtas wrote:
> >>> From: Ard Biesheuvel 
> >>>
> >>> The GIC architecture mandates that the CPU interface, which consists
> >>> of 2 consecutive 4 KB frames, can be mapped using separate mappings.
> >>> Since this is problematic on 64 KB pages, the MMU-400 aliases each
> >>> frame 16 times, and the two consecutive frames can be found at offset
> >>> 0xf000. This patch is intended to expose correct GICC alias via
> >>> MADT, once ACPI support is added.
> >>
> >> I'm afraid I don't quite understand this message.
> >>
> >> The change seems to be that the InterfaceBase moves from the first 4KB
> >> alias inside a 64KB page to the last alias within the same page.
> >> That seems valid, but I don't see how it resolves anything described
> >> in this message?
> >>
> 
> Because now, GICC + 4 KB will point at the second frame, and so the
> two frames appear adjacently, and precisely 4 KB apart. And at the
> same time, they are still covered by distinct 64 KB pages so it even
> works when running the OS with 64k pages.

Right, I was thinking it might be something like that, but I didn't
get that from the patch - commit message _or_ comment.

Maybe add something like "Use the last alias from the first series of
aliases as the base address, so that the first frame from the second
series becomes directly adjacent, whilst remaining covered by a
separate 64kB page"?

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

Re: [edk2] [platforms: PATCH 08/13] Marvell/Armada: Modify GICC alias

[Ard Biesheuvel]

On 10 October 2017 at 15:56, Marcin Wojtas  wrote:
> Hi Ard,
>
> 2017-10-10 16:53 GMT+02:00 Leif Lindholm :
>> On Mon, Oct 09, 2017 at 07:00:57PM +0200, Marcin Wojtas wrote:
>>> From: Ard Biesheuvel 
>>>
>>> The GIC architecture mandates that the CPU interface, which consists
>>> of 2 consecutive 4 KB frames, can be mapped using separate mappings.
>>> Since this is problematic on 64 KB pages, the MMU-400 aliases each
>>> frame 16 times, and the two consecutive frames can be found at offset
>>> 0xf000. This patch is intended to expose correct GICC alias via
>>> MADT, once ACPI support is added.
>>
>> I'm afraid I don't quite understand this message.
>>
>> The change seems to be that the InterfaceBase moves from the first 4KB
>> alias inside a 64KB page to the last alias within the same page.
>> That seems valid, but I don't see how it resolves anything described
>> in this message?
>>

Because now, GICC + 4 KB will point at the second frame, and so the
two frames appear adjacently, and precisely 4 KB apart. And at the
same time, they are still covered by distinct 64 KB pages so it even
works when running the OS with 64k pages.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 04/13] Marvell/Armada: Armada70x0Lib: Clean FV in the D-cache before boot

[Ard Biesheuvel]

On 10 October 2017 at 16:29, Leif Lindholm  wrote:
> On Tue, Oct 10, 2017 at 04:50:04PM +0200, Marcin Wojtas wrote:
>> 2017-10-10 16:43 GMT+02:00 Leif Lindholm :
>> > On Mon, Oct 09, 2017 at 07:00:53PM +0200, Marcin Wojtas wrote:
>> >> From: Ard Biesheuvel 
>> >>
>> >> To prevent cache coherency issues when chainloading via U-Boot, clean
>> >> and invalidate the FV image in the caches before re-enabling the MMU.
>> >
>> > Is this only relevant for chainloading (which is not the expected
>> > normal usage) or is it also important for warm-reset - for example for
>> > capsule update (at least from within OS)?
>>
>> Initially it was done for chainloading purpose - I don't use it
>> anymore, but just thought the patch itself is worth keeping. About
>> capsule update - I haven't tried it, it's been not the top priority
>> for me recently.
>>
>> > If the former, I would prefer for this to be conditionalised, and not
>> > included by default.
>>
>> How can we detect, that uefi is being chain-loaded?
>
> Oh, I meant compile time. Hence "not included by default".
>
> It has been a useful debug feature, but I don't think anyone is
> expecting to be routinely run either EDK2 on top of U-Boot or U-Boot
> on top of EDK2 on this platform.
>
>> > If the latter, please update the commit message.
>>
>> I'm considering keeping this patch aside, until it may become
>> necessary for capsule update, as I cannot guarantee now it's needed at
>> all. What's your recommendation?
>
> I'll wait to see what Ard has to say.
> So yes, it may make sense to move it out of the series for now.
>

We don't need this patch, I think. I don't remember the details, but
the FV should simply be cleaned to the PoC before entering UEFI.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 01/13] Marvell/Armada: Introduce platform initialization driver

[Ard Biesheuvel]

On 10 October 2017 at 16:26, Leif Lindholm  wrote:
> On Tue, Oct 10, 2017 at 05:06:42PM +0200, Marcin Wojtas wrote:
>> 2017-10-10 17:03 GMT+02:00 Leif Lindholm :
>> > On Tue, Oct 10, 2017 at 04:45:10PM +0200, Marcin Wojtas wrote:
>> >> Hi Leif,
>> >>
>> >> 2017-10-10 16:37 GMT+02:00 Leif Lindholm :
>> >> > On Mon, Oct 09, 2017 at 07:00:50PM +0200, Marcin Wojtas wrote:
>> >> >> In order to enable modification of dynamic PCD's for the libraries
>> >> >> and DXE drivers, this patch introduces new driver. It is
>> >> >> executed prior to other drivers. Mpp, ComPhy and Utmi libraries
>> >> >> initialization were moved from PrePi stage to DXE.
>> >> >>
>> >> >> To force the correct driver dispatch sequence, introduce a protocol 
>> >> >> GUID
>> >> >> and install the protocol as a NULL protocol when PlatInitDxe executes.
>> >> >>
>> >> >> Contributed-under: TianoCore Contribution Agreement 1.1
>> >> >> Signed-off-by: Marcin Wojtas 
>> >> >> Signed-off-by: Ard Biesheuvel 
>> >> >
>> >> > What does Ard's Signed-off-by signify here?
>> >> > (I know the authorship on some of these is a bit blurred, since you've
>> >> > been working together, but I'd like to be clear.)
>> >>
>> >> These were the lines, introducing/installing protocol GUID stuff. It
>> >> was in a small separate patch, but I squashed it into bigger one.
>> >
>> > Personally, I would in this instance do:
>> > 
>> > Ard
>> > 
>> >
>> > It's verbose, but reasonably clear.
>> >
>>
>> How about:
>>
>> In order to enable modification of dynamic PCD's for the libraries
>> and DXE drivers, this patch introduces new driver. It is
>> executed prior to other drivers. Mpp, ComPhy and Utmi libraries
>> initialization were moved from PrePi stage to DXE.
>>
>> Signed-off-by: Marcin Wojtas 
>>
>> To force the correct driver dispatch sequence, introduce a protocol GUID
>> and install the protocol as a NULL protocol when PlatInitDxe executes.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> Signed-off-by: Marcin Wojtas 
>>
>> ?
>>
>> Was that, what you meant?
>
> I think Contibuted-under: still needs to come first.
>
> I don't think we have an explicit policy for how to deal with
> multi-contributor patches. The ones we do see tend to just keep a
> single commit message and list the contributors.
>
> In Linux. it would be something like
> Signed-off-by: Marcin Wojtas 
> [Introduce protocol GUID to force correct driver dispatch order]
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 
>
> I would be quite happy to use the same format here.
>

Well, Tianocore still conflates authorship with a statement regarding
the origin of the contribution. I wonder how this is supposed to work
when Linaro engineers such as myself contribute code that was authored
by engineers working in member companies, e.g., Socionext. The license
and the contract that company has with Linaro give me the right to
contribute that code, but that does not make me the author, and I
cannot add a Signed-off-by that wasn't present when we received the
code (even if I knew the name of the author)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] Dynamic Tables

[Laszlo Ersek]

On 10/10/17 20:52, Evan Lloyd wrote:
> Hi Jiewen
> (I hope that is your personal name, not your surname - but it is a bit hard 
> for us barbarians to tell, sorry.)

Meta: I've been shamelessly exploiting the (apparent) custom that
@intel.com email addresses come in the following shapes:




If my heuristic has been wrong all this time, at least now I'll learn
about it :)

(Yes, I've noticed the use of commas in some names; they don't help. The
order they dictate is not uniform between cultures. Email address
schemes are more reliable, within an organization anyway.)

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

Re: [edk2] [PATCH 0/2] Dynamic Tables

[Evan Lloyd]

Hi Jiewen
(I hope that is your personal name, not your surname - but it is a bit hard for 
us barbarians to tell, sorry.)
Thank you for the very helpful feedback.
Responses are inline below.

> -Original Message-
> From: Yao, Jiewen [mailto:jiewen@intel.com]
> Sent: 10 October 2017 03:29
> To: Evan Lloyd ; edk2-devel@lists.01.org
> Cc: "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com;
> "ard.biesheu...@linaro.org"@arm.com; "Stephanie.Hughes-
> f...@arm.com"@arm.com; "thomas.abra...@arm.com"@arm.com;
> "arvind.chau...@arm.com"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "daniil.egra...@arm.com"@arm.com; Yao, Jiewen 
> Subject: RE: [edk2] [PATCH 0/2] Dynamic Tables
>
> HI Evan
> Thanks for the contribution.
>
> This is a very big feature. It may talk us more time to review and evaluate.
> At same time, one of our key MdeModule package maintainer is in paternity
> leave. It may be longer than usual.
>
> I notice you only defined ARM namespace in this patch, and implemented
> ARM library instance.
> Also most consumers of ConfigurationManager are from ARM platform
> package. So if it urgent from ARM platform, you may consider to check into
> ArmPkg at first.

[[Evan Lloyd]] This sounds sensible, and I will discuss it with Leif.  Another 
option might be to start up a new module.

>
>
>
> I only have a quick look at the patch. Would you please share more on the
> design philosophy?

[[Evan Lloyd]] You are quite right - we will put a document together on this.

>
> 1) It seems the final goal is still to generate ACPI table/SMBIOS 
> table/DevTree.
> You just introduce a way to manage how these tables are generated, right?

[[Evan Lloyd]] Yes.

>
> 2) Below definition is defined by the
> MdeModulePkg/Include/DynamicTables/ConfigurationManagerObject.h.
> Is there any industry standard to define below index? Or it is just defined by
> EDKII, and anyone can add extension here?

[[Evan Lloyd]] This is an initial submission for discussion, but there is not 
currently a relevant standard.  We are providing a "proof of concept" for 
discussion and review.  The ids are currently internal to edk2.  We do 
anticipate some sort of standard definition (for the information supplier) but 
that might be no more than a version of ConfigurationManagerObject.h

>
> +Object ID's in the ARM Namespace:
> +   0 - Reserved
> +   1 - Boot Architecture Info
> +   2 - CPU Info
> +   3 - Power Management Profile Info
> +   4 - GICC Info
> +   5 - GICD Info
> +   6 - GIC MSI Frame Info
> +   7 - GIC Redistributor Info
> +   8 - GIC ITS Info
> +   9 - Serial Console Port Info
> +  10 - Serial Debug Port Info
> +  12 - Generic Timer Info
> +  13 - Platform GT Block Info
> +  14 - Platform Generic Watchdog
> +  15 - PCI Configuration Space Info
> +  16 - Hypervisor Vendor Id
>
> 3) I am not sure if you have known about datahub protocol.
> (IntelFrameworkPkg\Include\Protocol\DataHub.h)

[[Evan Lloyd]] We did not.  We have not previously paid much attention to 
IntelFrameworkPkg  
We will have a look at the DataHub stuff though, to see how it fits.

> Long time ago, we have platform module filling the SMBIOS needed
> information to datahub (such as CPU INFO, Memory Info).
> The SMBIOS table is derived from datahub protocol. The setup driver can
> also from datahub.
> But later, we think it is an overdesign and datahub is no longer used in the
> new IA platform.
> People feel it is easier to fill industry defined SMBIOS record directly, 
> than to
> fill the EDK defined datahub record.
> They do not need to learn 2 different styles of data record format.
>
> To me, this seems similar to datahub. Please help us understand the key
> difference.

[[Evan Lloyd]]  From your description, there does seem to be an element of 
similarity with our submitted implementation.
However, our current code does not yet cover later options of obtaining the 
configuration data from a remote node, etc.
Our ultimate aim is to have a single UEFI image run on a range of platforms, 
taking guidance from the remote on what tables to publish with what content.  
You say "People feel it is easier to fill industry defined SMBIOS record 
directly, than to fill the EDK defined datahub record."  I do not question your 
statement, in fact I am sure you are right.  However, might those people be the 
ones who make a living filling "industry defined SMBIOS record directly"?  Our 
experience is that there is significant overhead in building complete sets of 
platform dependent tables for each variant of a machine, and we would like to 
reduce that.

>
> 4) In addition, EDKII/PI defined PCD (platform configuration database). It is
> an architecture way to manage the configuration data.
> We are also implementing structure PCD to let platform fill data easily.
> (https://github.com/tianocore/edk2-staging/tree/StructurePcd)
>
> I found some configuration can be as simple as a PCD, such as
> +  // Boot architecture 

Re: [edk2] [PATCH v2 1/2] SecurityPkg: make PcdOptionRomImageVerificationPolicy dynamic

[Laszlo Ersek]

On 10/10/17 15:46, Yao, Jiewen wrote:
> I am OK on this patch.
> 
> Reviewed-by: jiewen@intel.com

Thanks!

(Thanks to Qin as well!)

> BTW: Do you also need update PcdRemovableMediaImageVerificationPolicy and 
> PcdFixedMediaImageVerificationPolicy?

No, not at this time -- in OvmfPkg we are fine with the 0x04 defaults
for those PCDs, and don't intend to change them at all (either
dynamically or via a different fixed-at-build default).

The option ROM verification policy is special, because in a virt guest
environment, the host environment is trusted by default, and the option
ROMs come from the host environment. For this reason we originally
overrode the relevant PCD with value 0x00 -- ALWAYS_EXECUTE.

However, in SEV guests, the host environment is no longer trusted, and
we should restore the 0x04 policy for option ROMs. Given that SEV is
detected dynamically in OVMF, we need to massage the PCD dynamically too.

Do you think that all of these PCDs should be declared similarly (i.e.
that their declarations should permit the exact same set of storage
types, for symmetry)?

If so, do you prefer a follow-up patch for the DEC file, or a v3 of this
set?

Thanks!
Laszlo


> 
> 
> Thank you
> Yao Jiewen
> 
> 
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, October 10, 2017 7:28 PM
> To: Long, Qin ; Yao, Jiewen 
> Cc: Brijesh Singh ; edk2-devel@lists.01.org; Justen, 
> Jordan L ; Tom Lendacky ; 
> Zhang, Chao B 
> Subject: Re: [edk2] [PATCH v2 1/2] SecurityPkg: make 
> PcdOptionRomImageVerificationPolicy dynamic
> 
> Jiewen, Qin,
> 
> can you guys perhaps help with reviewing this patch? (The second patch
> in the series is for OvmfPkg, and it depends on this one.)
> 
> Thanks!
> Laszlo
> 
> On 10/05/17 22:16, Brijesh Singh wrote:
>> By default the image verification policy for option ROM images is 0x4
>> (DENY_EXECUTE_ON_SECURITY_VIOLATION) but the following OvmfPkg commit:
>>
>> 1fea9ddb4e3f OvmfPkg: execute option ROM images regardless of Secure Boot
>>
>> set it to 0x0 (ALWAYS_EXECUTE). This is fine because typically option
>> ROMs comes from host-side and most of the time cloud provider (i.e
>> hypervisor) have full access over a guest anyway. But when secure boot
>> is enabled, we would like to deny the execution of option ROM when
>> SEV is active. Having dynamic Pcd will give us flexibility to set the
>> security policy at the runtime.
>>
>> Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=728
>> Cc: Chao Zhang >
>> Cc: Jordan Justen 
>> >
>> Cc: Laszlo Ersek >
>> Cc: Tom Lendacky >
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Brijesh Singh 
>> >
>> ---
>>
>> Changes since v1:
>>  * Add Contributed-under tag
>>
>>  SecurityPkg/SecurityPkg.dec | 24 ++--
>>  1 file changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/SecurityPkg/SecurityPkg.dec b/SecurityPkg/SecurityPkg.dec
>> index 01bff01ed50a..4e32d172d7d9 100644
>> --- a/SecurityPkg/SecurityPkg.dec
>> +++ b/SecurityPkg/SecurityPkg.dec
>> @@ -230,18 +230,6 @@ [Ppis]
>>  #
>>
>>  [PcdsFixedAtBuild, PcdsPatchableInModule]
>> -  ## Image verification policy for OptionRom. Only following values are 
>> valid:
>> -  #  NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification 
>> and has been removed.
>> -  #  0x  Always trust the image.
>> -  #  0x0001  Never trust the image.
>> -  #  0x0002  Allow execution when there is security violation.
>> -  #  0x0003  Defer execution when there is security violation.
>> -  #  0x0004  Deny execution when there is security violation.
>> -  #  0x0005  Query user when there is security violation.
>> -  # @Prompt Set policy for the image from OptionRom.
>> -  # @ValidRange 0x8001 | 0x - 0x0005
>> -  
>> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04|UINT32|0x0001
>> -
>>## Image verification policy for removable media which includes CD-ROM, 
>> Floppy, USB and network.
>>#  Only following values are valid:
>>#  NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification 
>> and has been removed.
>> @@ -304,6 +292,18 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
>>
>> gEfiSecurityPkgTokenSpaceGuid.PcdStatusCodeSubClassTpmDevice|0x010D|UINT32|0x0007
>>
>>  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
>> +  ## Image verification policy for OptionRom. Only following values are 
>> valid:
>> +  #  NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI 

Re: [edk2] [PATCH] MdeModulePkg/Variable/RuntimeDxe: delete & lock MOR in the absence of SMM

[Laszlo Ersek]

On 10/10/17 15:54, Zeng, Star wrote:
> Could you help make the code consistent to call
> VariableServiceSetVariable() for the Attributes? One original for
> MorLock is using real attributes, the new you added for Mor will use 0
> attributes. How about to both use 0 attributes.

Sure, I can do that -- do you want me to set the attributes to 0 for the
MorLock deletion in the same patch, or should I do it in a separate
patch?

> Another question, why empty MorLockInitAtEndOfDxe() needs to be
> implemented in TcgMorLockDxe.c and called in VariableDxe.c?

Because otherwise we would break the promise we make in
"PrivilegePolymorphic.h":

>   Polymorphic functions that are called from both the privileged driver (i.e.,
>   the DXE_SMM variable module) and the non-privileged drivers (i.e., one or
>   both of the DXE_RUNTIME variable modules).
>
>   Each of these functions has two implementations, appropriate for privileged
>   vs. non-privileged driver code.

If I don't implement MorLockInitAtEndOfDxe() for VariableRuntimeDxe,
then we'll have a declaration with no definition in VariableRuntimeDxe,
and only one definition in total.

The empty function call should be optimized out in RELEASE builds
anyway (assuming LTO is used).

It's easy to remove the empty definition and the calls to it, but then
the purpose of "PrivilegePolymorphic.h" becomes less clear.

For complete clarity, I would have had to introduce *two* new header
files:

- one for SecureBootHook(), MorLockInit() and
  SetVariableCheckHandlerMor() -- to be used by both SMM and non-SMM,

- and another header file for just MorLockInitAtEndOfDxe() -- to be used
  only by SMM. (This is necessary because the call is made from
  "VariableSmm.c" to "TcgMorLockSmm.c").

I thought that introducing two new header files would not be accepted,
so I opted for one header file only. But then I felt that the empty
MorLockInitAtEndOfDxe() hook should be correctly implemented for
VariableRuntimeDxe too.

Thanks,
Laszlo


>
>
> Thanks,
> Star
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, October 10, 2017 9:25 PM
> To: edk2-devel-01 
> Cc: Dong, Eric ; Yao, Jiewen ; 
> Zeng, Star 
> Subject: [PATCH] MdeModulePkg/Variable/RuntimeDxe: delete & lock MOR in the 
> absence of SMM
>
> VariableRuntimeDxe deletes and locks the MorLock variable in
> MorLockInit(), with the argument that any protection provided by MorLock
> can be circumvented if MorLock can be overwritten by unprivileged code
> (i.e., outside of SMM).
>
> Extend the argument and the logic to the MOR variable, which is supposed
> to be protected by MorLock.
>
> This change was suggested by Star; it is inspired by earlier VariableSmm
> commit fda8f631edbb ("MdeModulePkg/Variable/RuntimeDxe: delete and lock
> OS-created MOR variable", 2017-10-03).
>
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Cc: Star Zeng 
> Suggested-by: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
>
> Notes:
> Repo:   https://github.com/lersek/edk2.git
> Branch: del_and_lock_mor_without_smm
>
>  MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c | 24 
> 
>  1 file changed, 24 insertions(+)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c 
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
> index 7142e2da2073..1610c7aa0706 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
> @@ -69,29 +69,53 @@ EFI_STATUS
>  MorLockInit (
>VOID
>)
>  {
>//
>// Always clear variable to report unsupported to OS.
>// The reason is that the DXE version is not proper to provide 
> *protection*.
>// BIOS should use SMM version variable driver to provide such capability.
>//
>VariableServiceSetVariable (
>  MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME,
>  ,
>  EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | 
> EFI_VARIABLE_RUNTIME_ACCESS,
>  0,
>  NULL
>  );
>
>//
>// Need set this variable to be read-only to prevent other module set it.
>//
>VariableLockRequestToLock (, 
> MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME, 
> );
> +
> +  //
> +  // The MOR variable can effectively improve platform security only when the
> +  // MorLock variable protects the MOR variable. In turn MorLock cannot be 
> made
> +  // secure without SMM support in the platform firmware (see above).
> +  //
> +  // Thus, delete the MOR variable, should it exist for any reason (some OSes
> +  // are known to create MOR unintentionally, in an attempt to set it), then
> +  // also lock the MOR variable, in order to prevent other modules from
> +  // creating it.
> +  //

Re: [edk2] [PATCH] MdeModulePkg/Bds: Remove assertion in BmCharToUint

[Laszlo Ersek]

On 10/10/17 10:39, Ruiyu Ni wrote:
> BmCharToUint() could be called using external data and it
> already contains logic to return -1 when data is invalid,
> so removing unnecessary assertion to avoid system hang.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Ard Biesheuvel 
> Cc: Laszlo Ersek 
> ---
>  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> index 11ab86792a..a3fa254245 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> @@ -420,7 +420,6 @@ BmCharToUint (
>  return (Char - L'A' + 0xA);
>}
>  
> -  ASSERT (FALSE);
>return (UINTN) -1;
>  }
>  
> 

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [PATCH] MdeModulePkg/Bds: Check variable name even OptionNumber is NULL

[Laszlo Ersek]

On 10/10/17 10:58, Ruiyu Ni wrote:
> Current implementation skips to check whether the last four
> characters are digits when the OptionNumber is NULL.
> Even worse, it may incorrectly return FALSE when OptionNumber is
> NULL.
> 
> The patch fixes it to always check the variable name even
> OptionNumber is NULL.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Ard Biesheuvel 
> Cc: Laszlo Ersek 
> ---
>  .../Library/UefiBootManagerLib/BmLoadOption.c  | 45 
> ++
>  1 file changed, 30 insertions(+), 15 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> index b0a35058d0..32918caf32 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> @@ -785,6 +785,8 @@ EfiBootManagerIsValidLoadOptionVariableName (
>UINTN VariableNameLen;
>UINTN Index;
>UINTN Uint;
> +  EFI_BOOT_MANAGER_LOAD_OPTION_TYPE LocalOptionType;
> +  UINT16LocalOptionNumber;
>  
>if (VariableName == NULL) {
>  return FALSE;
> @@ -792,39 +794,52 @@ EfiBootManagerIsValidLoadOptionVariableName (
>  
>VariableNameLen = StrLen (VariableName);
>  
> +  //
> +  // Return FALSE when the variable name length is too small.
> +  //
>if (VariableNameLen <= 4) {
>  return FALSE;
>}
>  
> -  for (Index = 0; Index < ARRAY_SIZE (mBmLoadOptionName); Index++) {
> -if ((VariableNameLen - 4 == StrLen (mBmLoadOptionName[Index])) &&
> -(StrnCmp (VariableName, mBmLoadOptionName[Index], VariableNameLen - 
> 4) == 0)
> +  //
> +  // Return FALSE when the variable name doesn't start with 
> Driver/SysPrep/Boot/PlatformRecovery.
> +  //
> +  for (LocalOptionType = 0; LocalOptionType < ARRAY_SIZE 
> (mBmLoadOptionName); LocalOptionType++) {
> +if ((VariableNameLen - 4 == StrLen (mBmLoadOptionName[LocalOptionType])) 
> &&
> +(StrnCmp (VariableName, mBmLoadOptionName[LocalOptionType], 
> VariableNameLen - 4) == 0)
>  ) {
>break;
>  }
>}
> +  if (LocalOptionType == ARRAY_SIZE (mBmLoadOptionName)) {
> +return FALSE;
> +  }
>  
> -  if (Index == ARRAY_SIZE (mBmLoadOptionName)) {
> +  //
> +  // Return FALSE when the last four characters are not hex digits.
> +  //
> +  LocalOptionNumber = 0;
> +  for (Index = VariableNameLen - 4; Index < VariableNameLen; Index++) {
> +Uint = BmCharToUint (VariableName[Index]);
> +if (Uint == -1) {
> +  break;
> +} else {
> +  LocalOptionNumber = (UINT16) Uint + LocalOptionNumber * 0x10;
> +}
> +  }
> +  if (Index != VariableNameLen) {
>  return FALSE;
>}
>  
>if (OptionType != NULL) {
> -*OptionType = (EFI_BOOT_MANAGER_LOAD_OPTION_TYPE) Index;
> +*OptionType = LocalOptionType;
>}
>  
>if (OptionNumber != NULL) {
> -*OptionNumber = 0;
> -for (Index = VariableNameLen - 4; Index < VariableNameLen; Index++) {
> -  Uint = BmCharToUint (VariableName[Index]);
> -  if (Uint == -1) {
> -break;
> -  } else {
> -*OptionNumber = (UINT16) Uint + *OptionNumber * 0x10;
> -  }
> -}
> +*OptionNumber = LocalOptionNumber;
>}
>  
> -  return (BOOLEAN) (Index == VariableNameLen);
> +  return TRUE;
>  }
>  
>  /**
> 

I have some superficial comments:

- I think the subject should say

MdeModulePkg/Bds: Check variable name even *if* OptionNumber is NULL

- I'm not a huge fan of using enum types for loop counters; however, in
this case, I verified that there is LoadOptionTypeMax, and it equals
ARRAY_SIZE (mBmLoadOptionName). So it should be safe. If we want to be
more explicit about this, we could replace

  CHAR16 *mBmLoadOptionName[] = {

with

  CHAR16 *mBmLoadOptionName[LoadOptionTypeMax] = {

Anyway,

Reviewed-by: Laszlo Ersek 

Ard, can you test this patch in your original environment?

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

Re: [edk2] [PATCH v2 1/2] SecurityPkg: make PcdOptionRomImageVerificationPolicy dynamic

[Long, Qin]

The patch looks good to me.

Reviewed-by: Long Qin 


Best Regards & Thanks,
LONG, Qin

From: Yao, Jiewen
Sent: Tuesday, October 10, 2017 9:47 PM
To: Laszlo Ersek ; Long, Qin 
Cc: Brijesh Singh ; edk2-devel@lists.01.org; Justen, 
Jordan L ; Tom Lendacky ; 
Zhang, Chao B 
Subject: RE: [edk2] [PATCH v2 1/2] SecurityPkg: make 
PcdOptionRomImageVerificationPolicy dynamic

I am OK on this patch.

Reviewed-by: jiewen@intel.com

BTW: Do you also need update PcdRemovableMediaImageVerificationPolicy and 
PcdFixedMediaImageVerificationPolicy?


Thank you
Yao Jiewen


From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, October 10, 2017 7:28 PM
To: Long, Qin >; Yao, Jiewen 
>
Cc: Brijesh Singh >; 
edk2-devel@lists.01.org; Justen, Jordan L 
>; Tom Lendacky 
>; Zhang, Chao B 
>
Subject: Re: [edk2] [PATCH v2 1/2] SecurityPkg: make 
PcdOptionRomImageVerificationPolicy dynamic

Jiewen, Qin,

can you guys perhaps help with reviewing this patch? (The second patch
in the series is for OvmfPkg, and it depends on this one.)

Thanks!
Laszlo

On 10/05/17 22:16, Brijesh Singh wrote:
> By default the image verification policy for option ROM images is 0x4
> (DENY_EXECUTE_ON_SECURITY_VIOLATION) but the following OvmfPkg commit:
>
> 1fea9ddb4e3f OvmfPkg: execute option ROM images regardless of Secure Boot
>
> set it to 0x0 (ALWAYS_EXECUTE). This is fine because typically option
> ROMs comes from host-side and most of the time cloud provider (i.e
> hypervisor) have full access over a guest anyway. But when secure boot
> is enabled, we would like to deny the execution of option ROM when
> SEV is active. Having dynamic Pcd will give us flexibility to set the
> security policy at the runtime.
>
> Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=728
> Cc: Chao Zhang >
> Cc: Jordan Justen 
> >
> Cc: Laszlo Ersek >
> Cc: Tom Lendacky >
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> >
> ---
>
> Changes since v1:
>  * Add Contributed-under tag
>
>  SecurityPkg/SecurityPkg.dec | 24 ++--
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/SecurityPkg/SecurityPkg.dec b/SecurityPkg/SecurityPkg.dec
> index 01bff01ed50a..4e32d172d7d9 100644
> --- a/SecurityPkg/SecurityPkg.dec
> +++ b/SecurityPkg/SecurityPkg.dec
> @@ -230,18 +230,6 @@ [Ppis]
>  #
>
>  [PcdsFixedAtBuild, PcdsPatchableInModule]
> -  ## Image verification policy for OptionRom. Only following values are 
> valid:
> -  #  NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification 
> and has been removed.
> -  #  0x  Always trust the image.
> -  #  0x0001  Never trust the image.
> -  #  0x0002  Allow execution when there is security violation.
> -  #  0x0003  Defer execution when there is security violation.
> -  #  0x0004  Deny execution when there is security violation.
> -  #  0x0005  Query user when there is security violation.
> -  # @Prompt Set policy for the image from OptionRom.
> -  # @ValidRange 0x8001 | 0x - 0x0005
> -  
> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04|UINT32|0x0001
> -
>## Image verification policy for removable media which includes CD-ROM, 
> Floppy, USB and network.
>#  Only following values are valid:
>#  NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification 
> and has been removed.
> @@ -304,6 +292,18 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
>
> gEfiSecurityPkgTokenSpaceGuid.PcdStatusCodeSubClassTpmDevice|0x010D|UINT32|0x0007
>
>  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> +  ## Image verification policy for OptionRom. Only following values are 
> valid:
> +  #  NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification 
> and has been removed.
> +  #  0x  Always trust the image.
> +  #  0x0001  Never trust the image.
> +  #  0x0002  Allow execution when there is security violation.
> +  #  0x0003  Defer execution when there is security violation.
> +  #  0x0004  Deny execution when there is security violation.
> +  #  0x0005  Query 

Re: [edk2] [PATCH 0/2] Add FPDT Acpi table

[Leif Lindholm]

Thanks.

Pushed as a63be426f8 (edk2) and 5d6506e4e9 (edk2-platforms).

(I also deleted a stray "Change-id" tag from each commit message.)

Regards,

Leif

On Tue, Oct 10, 2017 at 04:11:15PM +, Evan Lloyd wrote:
> Hi Leif.
> Firstly - sorry I thought we had this sorted.
> 
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: 09 October 2017 12:22
> > To: Evan Lloyd 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [PATCH 0/2] Add FPDT Acpi table
> >
> > On Fri, Sep 22, 2017 at 05:18:05PM +0100, evan.ll...@arm.com wrote:
> > > From: EvanLloyd 
> > > Paired patches for edk2 and edk2-platforms that add an FPDT acpi
> > > table.
> > > This is useful for monitoring firmware performance, etc.
> >
> > With Graeme's Reviewed-by, I'm happy with thise series.
> > However, can you confirm your intent was to submit this series under
> > Tianocore Contribution Agreement 1.1?
> 
> [[Evan Lloyd]] Secondly - yes I did intend to submit under Tianocore 
> Contribution Agreement 1.1.  Frankly, I'm a bit baffled by how this 1.0 got 
> through.
> 
> Regards,
> Evan
> >
> > I can fold that in when pushing.
> >
> > Regards,
> >
> > Leif
> >
> > > Alexei Fedorov (1):
> > >   ArmPlatformPkg: Store initial timer value
> > >
> > >  ArmPlatformPkg/PrePi/PeiMPCore.inf  |  3 ++-
> > > ArmPlatformPkg/PrePi/PeiUniCore.inf |  3 ++-
> > >  ArmPlatformPkg/PrePi/PrePi.c| 10 +-
> > >  3 files changed, 13 insertions(+), 3 deletions(-)
> > >
> > > See https://github.com/EvanLloyd/tianocore/tree/164_FPDT_v1
> > >
> > > Alexei Fedorov (1):
> > >   ARM/JunoPkg: Add support for FPDT table.
> > >
> > >  Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 9 -
> > >  Platform/ARM/JunoPkg/ArmJuno.dsc | 9 +
> > >  Platform/ARM/JunoPkg/ArmJuno.fdf | 6 ++
> > >  3 files changed, 23 insertions(+), 1 deletion(-)
> > >
> > > See https://github.com/EvanLloyd/edk2-platforms/tree/164_FPDT_v1
> > >
> > > --
> > > Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
> > >
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] Add FPDT Acpi table

[Evan Lloyd]

Hi Leif.
Firstly - sorry I thought we had this sorted.

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: 09 October 2017 12:22
> To: Evan Lloyd 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [PATCH 0/2] Add FPDT Acpi table
>
> On Fri, Sep 22, 2017 at 05:18:05PM +0100, evan.ll...@arm.com wrote:
> > From: EvanLloyd 
> > Paired patches for edk2 and edk2-platforms that add an FPDT acpi
> > table.
> > This is useful for monitoring firmware performance, etc.
>
> With Graeme's Reviewed-by, I'm happy with thise series.
> However, can you confirm your intent was to submit this series under
> Tianocore Contribution Agreement 1.1?

[[Evan Lloyd]] Secondly - yes I did intend to submit under Tianocore 
Contribution Agreement 1.1.  Frankly, I'm a bit baffled by how this 1.0 got 
through.

Regards,
Evan
>
> I can fold that in when pushing.
>
> Regards,
>
> Leif
>
> > Alexei Fedorov (1):
> >   ArmPlatformPkg: Store initial timer value
> >
> >  ArmPlatformPkg/PrePi/PeiMPCore.inf  |  3 ++-
> > ArmPlatformPkg/PrePi/PeiUniCore.inf |  3 ++-
> >  ArmPlatformPkg/PrePi/PrePi.c| 10 +-
> >  3 files changed, 13 insertions(+), 3 deletions(-)
> >
> > See https://github.com/EvanLloyd/tianocore/tree/164_FPDT_v1
> >
> > Alexei Fedorov (1):
> >   ARM/JunoPkg: Add support for FPDT table.
> >
> >  Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 9 -
> >  Platform/ARM/JunoPkg/ArmJuno.dsc | 9 +
> >  Platform/ARM/JunoPkg/ArmJuno.fdf | 6 ++
> >  3 files changed, 23 insertions(+), 1 deletion(-)
> >
> > See https://github.com/EvanLloyd/edk2-platforms/tree/164_FPDT_v1
> >
> > --
> > Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
> >
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 04/13] Marvell/Armada: Armada70x0Lib: Clean FV in the D-cache before boot

[Leif Lindholm]

On Tue, Oct 10, 2017 at 04:50:04PM +0200, Marcin Wojtas wrote:
> 2017-10-10 16:43 GMT+02:00 Leif Lindholm :
> > On Mon, Oct 09, 2017 at 07:00:53PM +0200, Marcin Wojtas wrote:
> >> From: Ard Biesheuvel 
> >>
> >> To prevent cache coherency issues when chainloading via U-Boot, clean
> >> and invalidate the FV image in the caches before re-enabling the MMU.
> >
> > Is this only relevant for chainloading (which is not the expected
> > normal usage) or is it also important for warm-reset - for example for
> > capsule update (at least from within OS)?
> 
> Initially it was done for chainloading purpose - I don't use it
> anymore, but just thought the patch itself is worth keeping. About
> capsule update - I haven't tried it, it's been not the top priority
> for me recently.
> 
> > If the former, I would prefer for this to be conditionalised, and not
> > included by default.
> 
> How can we detect, that uefi is being chain-loaded?

Oh, I meant compile time. Hence "not included by default".

It has been a useful debug feature, but I don't think anyone is
expecting to be routinely run either EDK2 on top of U-Boot or U-Boot
on top of EDK2 on this platform.

> > If the latter, please update the commit message.
> 
> I'm considering keeping this patch aside, until it may become
> necessary for capsule update, as I cannot guarantee now it's needed at
> all. What's your recommendation?

I'll wait to see what Ard has to say.
So yes, it may make sense to move it out of the series for now.

Regards,

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

Re: [edk2] [platforms: PATCH 01/13] Marvell/Armada: Introduce platform initialization driver

[Leif Lindholm]

On Tue, Oct 10, 2017 at 05:06:42PM +0200, Marcin Wojtas wrote:
> 2017-10-10 17:03 GMT+02:00 Leif Lindholm :
> > On Tue, Oct 10, 2017 at 04:45:10PM +0200, Marcin Wojtas wrote:
> >> Hi Leif,
> >>
> >> 2017-10-10 16:37 GMT+02:00 Leif Lindholm :
> >> > On Mon, Oct 09, 2017 at 07:00:50PM +0200, Marcin Wojtas wrote:
> >> >> In order to enable modification of dynamic PCD's for the libraries
> >> >> and DXE drivers, this patch introduces new driver. It is
> >> >> executed prior to other drivers. Mpp, ComPhy and Utmi libraries
> >> >> initialization were moved from PrePi stage to DXE.
> >> >>
> >> >> To force the correct driver dispatch sequence, introduce a protocol GUID
> >> >> and install the protocol as a NULL protocol when PlatInitDxe executes.
> >> >>
> >> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> >> Signed-off-by: Marcin Wojtas 
> >> >> Signed-off-by: Ard Biesheuvel 
> >> >
> >> > What does Ard's Signed-off-by signify here?
> >> > (I know the authorship on some of these is a bit blurred, since you've
> >> > been working together, but I'd like to be clear.)
> >>
> >> These were the lines, introducing/installing protocol GUID stuff. It
> >> was in a small separate patch, but I squashed it into bigger one.
> >
> > Personally, I would in this instance do:
> > 
> > Ard
> > 
> >
> > It's verbose, but reasonably clear.
> >
> 
> How about:
> 
> In order to enable modification of dynamic PCD's for the libraries
> and DXE drivers, this patch introduces new driver. It is
> executed prior to other drivers. Mpp, ComPhy and Utmi libraries
> initialization were moved from PrePi stage to DXE.
> 
> Signed-off-by: Marcin Wojtas 
> 
> To force the correct driver dispatch sequence, introduce a protocol GUID
> and install the protocol as a NULL protocol when PlatInitDxe executes.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 
> 
> ?
> 
> Was that, what you meant?

I think Contibuted-under: still needs to come first.

I don't think we have an explicit policy for how to deal with
multi-contributor patches. The ones we do see tend to just keep a
single commit message and list the contributors.

In Linux. it would be something like
Signed-off-by: Marcin Wojtas 
[Introduce protocol GUID to force correct driver dispatch order]
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 

I would be quite happy to use the same format here.

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

Re: [edk2] [platforms: PATCH 01/13] Marvell/Armada: Introduce platform initialization driver

[Marcin Wojtas]

2017-10-10 17:03 GMT+02:00 Leif Lindholm :
> On Tue, Oct 10, 2017 at 04:45:10PM +0200, Marcin Wojtas wrote:
>> Hi Leif,
>>
>> 2017-10-10 16:37 GMT+02:00 Leif Lindholm :
>> > On Mon, Oct 09, 2017 at 07:00:50PM +0200, Marcin Wojtas wrote:
>> >> In order to enable modification of dynamic PCD's for the libraries
>> >> and DXE drivers, this patch introduces new driver. It is
>> >> executed prior to other drivers. Mpp, ComPhy and Utmi libraries
>> >> initialization were moved from PrePi stage to DXE.
>> >>
>> >> To force the correct driver dispatch sequence, introduce a protocol GUID
>> >> and install the protocol as a NULL protocol when PlatInitDxe executes.
>> >>
>> >> Contributed-under: TianoCore Contribution Agreement 1.1
>> >> Signed-off-by: Marcin Wojtas 
>> >> Signed-off-by: Ard Biesheuvel 
>> >
>> > What does Ard's Signed-off-by signify here?
>> > (I know the authorship on some of these is a bit blurred, since you've
>> > been working together, but I'd like to be clear.)
>>
>> These were the lines, introducing/installing protocol GUID stuff. It
>> was in a small separate patch, but I squashed it into bigger one.
>
> Personally, I would in this instance do:
> 
> Ard
> 
>
> It's verbose, but reasonably clear.
>

How about:

In order to enable modification of dynamic PCD's for the libraries
and DXE drivers, this patch introduces new driver. It is
executed prior to other drivers. Mpp, ComPhy and Utmi libraries
initialization were moved from PrePi stage to DXE.

Signed-off-by: Marcin Wojtas 

To force the correct driver dispatch sequence, introduce a protocol GUID
and install the protocol as a NULL protocol when PlatInitDxe executes.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 

?

Was that, what you meant?

>> >
>> >> ---
>> >>  Platform/Marvell/Armada/Armada.dsc.inc|  3 ++
>> >>  Platform/Marvell/Armada/Armada70x0.fdf|  5 +++
>> >>  Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c | 44 
>> >> 
>> >>  Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf   | 44 
>> >> 
>> >>  Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.c | 11 -
>> >>  Platform/Marvell/Marvell.dec  |  5 +++
>> >>  6 files changed, 101 insertions(+), 11 deletions(-)
>> >>
>> >> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
>> >> b/Platform/Marvell/Armada/Armada.dsc.inc
>> >> index 89fb7e7..417bb0c 100644
>> >> --- a/Platform/Marvell/Armada/Armada.dsc.inc
>> >> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
>> >> @@ -378,6 +378,9 @@
>> >>ArmPkg/Drivers/TimerDxe/TimerDxe.inf
>> >>ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
>> >>
>> >> +  # Platform Initialization
>> >> +  Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
>> >> +
>> >># Platform drivers
>> >>Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
>> >>MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
>> >> diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
>> >> b/Platform/Marvell/Armada/Armada70x0.fdf
>> >> index c861e78..763d76a 100644
>> >> --- a/Platform/Marvell/Armada/Armada70x0.fdf
>> >> +++ b/Platform/Marvell/Armada/Armada70x0.fdf
>> >> @@ -89,6 +89,11 @@ FvNameGuid = 
>> >> 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
>> >>
>> >>INF MdeModulePkg/Core/Dxe/DxeMain.inf
>> >>
>> >> +  #
>> >> +  # Platform Initialization
>> >> +  #
>> >> +  INF Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
>> >> +
>> >># PI DXE Drivers producing Architectural Protocols (EFI Services)
>> >>INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
>> >>INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
>> >> diff --git a/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c 
>> >> b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c
>> >> new file mode 100644
>> >> index 000..919454b
>> >> --- /dev/null
>> >> +++ b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c
>> >> @@ -0,0 +1,44 @@
>> >> +/** @file
>> >> +  Copyright (C) Marvell International Ltd. and its affiliates
>> >
>> > We normally need a year here as well.
>> > If Ard has co-authored parts, I guess we should have Linaro copyright
>> > notice on affected files as well.
>>
>> I have no problem with that, if you find it appropriate, given my
>> explanation above.
>
> Personally I dont mind much, but I think it would be more correct.
>

Ok, will add it in v2.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 01/13] Marvell/Armada: Introduce platform initialization driver

[Leif Lindholm]

On Tue, Oct 10, 2017 at 04:45:10PM +0200, Marcin Wojtas wrote:
> Hi Leif,
> 
> 2017-10-10 16:37 GMT+02:00 Leif Lindholm :
> > On Mon, Oct 09, 2017 at 07:00:50PM +0200, Marcin Wojtas wrote:
> >> In order to enable modification of dynamic PCD's for the libraries
> >> and DXE drivers, this patch introduces new driver. It is
> >> executed prior to other drivers. Mpp, ComPhy and Utmi libraries
> >> initialization were moved from PrePi stage to DXE.
> >>
> >> To force the correct driver dispatch sequence, introduce a protocol GUID
> >> and install the protocol as a NULL protocol when PlatInitDxe executes.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Marcin Wojtas 
> >> Signed-off-by: Ard Biesheuvel 
> >
> > What does Ard's Signed-off-by signify here?
> > (I know the authorship on some of these is a bit blurred, since you've
> > been working together, but I'd like to be clear.)
> 
> These were the lines, introducing/installing protocol GUID stuff. It
> was in a small separate patch, but I squashed it into bigger one.

Personally, I would in this instance do:

Ard


It's verbose, but reasonably clear.

> >
> >> ---
> >>  Platform/Marvell/Armada/Armada.dsc.inc|  3 ++
> >>  Platform/Marvell/Armada/Armada70x0.fdf|  5 +++
> >>  Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c | 44 
> >> 
> >>  Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf   | 44 
> >> 
> >>  Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.c | 11 -
> >>  Platform/Marvell/Marvell.dec  |  5 +++
> >>  6 files changed, 101 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
> >> b/Platform/Marvell/Armada/Armada.dsc.inc
> >> index 89fb7e7..417bb0c 100644
> >> --- a/Platform/Marvell/Armada/Armada.dsc.inc
> >> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
> >> @@ -378,6 +378,9 @@
> >>ArmPkg/Drivers/TimerDxe/TimerDxe.inf
> >>ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
> >>
> >> +  # Platform Initialization
> >> +  Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
> >> +
> >># Platform drivers
> >>Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
> >>MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
> >> diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
> >> b/Platform/Marvell/Armada/Armada70x0.fdf
> >> index c861e78..763d76a 100644
> >> --- a/Platform/Marvell/Armada/Armada70x0.fdf
> >> +++ b/Platform/Marvell/Armada/Armada70x0.fdf
> >> @@ -89,6 +89,11 @@ FvNameGuid = 
> >> 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
> >>
> >>INF MdeModulePkg/Core/Dxe/DxeMain.inf
> >>
> >> +  #
> >> +  # Platform Initialization
> >> +  #
> >> +  INF Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
> >> +
> >># PI DXE Drivers producing Architectural Protocols (EFI Services)
> >>INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
> >>INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
> >> diff --git a/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c 
> >> b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c
> >> new file mode 100644
> >> index 000..919454b
> >> --- /dev/null
> >> +++ b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c
> >> @@ -0,0 +1,44 @@
> >> +/** @file
> >> +  Copyright (C) Marvell International Ltd. and its affiliates
> >
> > We normally need a year here as well.
> > If Ard has co-authored parts, I guess we should have Linaro copyright
> > notice on affected files as well.
> 
> I have no problem with that, if you find it appropriate, given my
> explanation above.

Personally I dont mind much, but I think it would be more correct.

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

Re: [edk2] [platforms: PATCH 11/13] Marvell/Armada: Remove outdated SEC alignment override

[Marcin Wojtas]

2017-10-10 16:58 GMT+02:00 Leif Lindholm :
> On Mon, Oct 09, 2017 at 07:01:00PM +0200, Marcin Wojtas wrote:
>> From: Ard Biesheuvel 
>>
>> The FDFs no longer require explicit alignment for sections containing
>> aligned objects, so change it to 'Auto' and FIXED (which allows some
>> padding to be removed), and remove some other cruft while at it.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> Signed-off-by: Marcin Wojtas 
>> ---
>>  Platform/Marvell/Armada/Armada70x0.fdf | 11 ++-
>>  1 file changed, 2 insertions(+), 9 deletions(-)
>>
>> diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
>> b/Platform/Marvell/Armada/Armada70x0.fdf
>> index 2c3efe0..15ae52b 100644
>> --- a/Platform/Marvell/Armada/Armada70x0.fdf
>> +++ b/Platform/Marvell/Armada/Armada70x0.fdf
>> @@ -235,16 +235,9 @@ READ_LOCK_STATUS   = TRUE
>>  #
>>  
>>
>> -[Rule.ARM.SEC]
>> -  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
>> -TE  TEAlign = 32$(INF_OUTPUT)/$(MODULE_NAME).efi
>> -  }
>> -
>> -# The AArch64 Vector Table requires a 2K alignment that is not supported by 
>> the FDF specification.
>> -# It is the reason 4K is used instead of 2K for the module alignment.
>>  [Rule.AARCH64.SEC]
>> -  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
>> -TE  TEAlign = 4K$(INF_OUTPUT)/$(MODULE_NAME).efi
>> +  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
>> +TE  TEAlign = Auto$(INF_OUTPUT)/$(MODULE_NAME).efi
>
> This does appear to arbitrarily increase indentation of the last entry
> on the line by 2, shifting it out of alignment with later entries in
> the file?
>

I'll correct indentation in v2.

Thanks,
Marcin

> /
> Leif
>
>>}
>>
>>  [Rule.Common.PEI_CORE]
>> --
>> 1.8.3.1
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 13/13] Marvell/Documentation: Follow EDK2 coding style in the PortingGuide

[Leif Lindholm]

On Mon, Oct 09, 2017 at 07:01:02PM +0200, Marcin Wojtas wrote:
> This patch removes tabs and wrong line endings in the file, maiking
> it acceptable to the PatchCheck.py script.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 

Much obliged :)

Reviewed-by: Leif Lindholm 

> ---
>  Silicon/Marvell/Documentation/PortingGuide.txt | 800 ++--
>  1 file changed, 400 insertions(+), 400 deletions(-)
> 
> diff --git a/Silicon/Marvell/Documentation/PortingGuide.txt 
> b/Silicon/Marvell/Documentation/PortingGuide.txt
> index f0da515..66ec918 100644
> --- a/Silicon/Marvell/Documentation/PortingGuide.txt
> +++ b/Silicon/Marvell/Documentation/PortingGuide.txt
> @@ -1,400 +1,400 @@
> -UEFI Porting Guide
> -==
> -
> -This document provides instructions for adding support for new Marvell Armada
> -board. For the sake of simplicity new Marvell board will be called 
> "new_board".
> -
> -1. Create configuration files for new target
> - 1.1 Create FDF file for new board
> -
> -  - Copy and rename 
> edk2-platforms/Platform/Marvell/Armada/Armada70x0.fdf to
> -edk2-platforms/Platform/Marvell/Armada/new_board.fdf
> -  - Change the first no-comment line:
> -[FD.Armada70x0_EFI] to [FD.{new_board}_EFI]
> -
> - 1.2 Create DSC file for new board
> -
> -  - Add new_board.dsc file to edk2-platforms/Platform/Marvell/Armada 
> directory
> -  - Insert following [Defines] section to new_board.dsc:
> -
> - [Defines]
> -   PLATFORM_NAME  = {new_board}
> -   PLATFORM_GUID  = 
> {newly_generated_GUID}
> -   PLATFORM_VERSION   = 0.1
> -   DSC_SPECIFICATION  = 0x00010019
> -   OUTPUT_DIRECTORY   = {output_directory}
> -   SUPPORTED_ARCHITECTURES= AARCH64
> -   BUILD_TARGETS  = DEBUG|RELEASE
> -   SKUID_IDENTIFIER   = DEFAULT
> -   FLASH_DEFINITION   = {path_to_fdf_file}
> -
> -  - Add "!include Armada.dsc.inc" entry to new_board.dsc
> -
> -2. Driver support
> - - According to content of files from
> -   edk2-platforms/Silicon/Marvell/Documentation/PortingGuide.txt
> -   insert PCD entries into new_board.dsc for every needed interface (as 
> listed below).
> -
> -3. Compilation
> - - Refer to edk2-platforms/Platform/Marvell/Readme.md. Remember to change
> -   {platform} to new_board in order to point build system to newly created 
> DSC file.
> -
> -4. Output file
> - - Output files (and among others FD file, which may be used by ATF) are
> -   generated under directory pointed by "OUTPUT_DIRECTORY" entry (see point 
> 1.2).
> -
> -
> -COMPHY configuration
> -
> -In order to configure ComPhy library, following PCDs are available:
> -
> -  - gMarvellTokenSpaceGuid.PcdComPhyDevices
> -
> -This array indicates, which ones of the ComPhy chips defined in
> -MVHW_COMPHY_DESC template will be configured.
> -
> -Every ComPhy PCD has  part where  stands for chip ID (order is not
> -important, but configuration will be set for first PcdComPhyChipCount chips).
> -
> -Every chip has 3 ComPhy PCDs and three of them comprise per-board lanes
> -settings for this chip. Their format is array of up to 10 values reflecting
> -defined numbers for SPEED/TYPE/INVERT, whose description can be found in:
> -
> -  OpenPlatformPkg/Platforms/Marvell/Library/ComPhyLib/ComPhyLib.h
> -
> -  - gMarvellTokenSpaceGuid.PcdChip0ComPhyTypes
> - (Array of types - currently supported are:
> -
> - CP_UNCONNECTED  0x0
> - CP_PCIE00x1
> - CP_PCIE10x2
> - CP_PCIE20x3
> - CP_PCIE30x4
> - CP_SATA00x5
> - CP_SATA10x6
> - CP_SATA20x7
> - CP_SATA30x8
> - CP_SGMII0   0x9
> - CP_SGMII1   0xA
> - CP_SGMII2   0xB
> - CP_SGMII3   0xC
> - CP_QSGMII   0xD
> - CP_USB3_HOST0   0xE
> - CP_USB3_HOST1   0xF
> - CP_USB3_DEVICE  0x10
> - CP_XAUI00x11
> - CP_XAUI10x12
> - CP_XAUI20x13
> - CP_XAUI30x14
> - CP_RXAUI0   0x15
> - CP_RXAUI1   0x16
> - CP_SFI  0x17 )
> -
> -  - gMarvellTokenSpaceGuid.PcdChip0ComPhySpeeds
> 

Re: [edk2] [platforms: PATCH 12/13] Marvell/Armada: Add the UefiPxeBcDxe driver

[Leif Lindholm]

On Mon, Oct 09, 2017 at 07:01:01PM +0200, Marcin Wojtas wrote:
> From: Ard Biesheuvel 
> 
> This driver allows automatic booting via the network.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Marvell/Armada/Armada.dsc.inc | 1 +
>  Platform/Marvell/Armada/Armada70x0.fdf | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
> b/Platform/Marvell/Armada/Armada.dsc.inc
> index 5a5fde9..1aa485c 100644
> --- a/Platform/Marvell/Armada/Armada.dsc.inc
> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
> @@ -412,6 +412,7 @@
>MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
>MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
>MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
> +  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
>Platform/Marvell/Drivers/Net/MvMdioDxe/MvMdioDxe.inf
>Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.inf
>Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.inf
> diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
> b/Platform/Marvell/Armada/Armada70x0.fdf
> index 15ae52b..bf54c6e 100644
> --- a/Platform/Marvell/Armada/Armada70x0.fdf
> +++ b/Platform/Marvell/Armada/Armada70x0.fdf
> @@ -125,6 +125,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
>INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
>INF MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
>INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
> +  INF MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
>INF Platform/Marvell/Drivers/Net/MvMdioDxe/MvMdioDxe.inf
>INF Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.inf
>INF Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.inf
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 11/13] Marvell/Armada: Remove outdated SEC alignment override

[Leif Lindholm]

On Mon, Oct 09, 2017 at 07:01:00PM +0200, Marcin Wojtas wrote:
> From: Ard Biesheuvel 
> 
> The FDFs no longer require explicit alignment for sections containing
> aligned objects, so change it to 'Auto' and FIXED (which allows some
> padding to be removed), and remove some other cruft while at it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Armada/Armada70x0.fdf | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
> b/Platform/Marvell/Armada/Armada70x0.fdf
> index 2c3efe0..15ae52b 100644
> --- a/Platform/Marvell/Armada/Armada70x0.fdf
> +++ b/Platform/Marvell/Armada/Armada70x0.fdf
> @@ -235,16 +235,9 @@ READ_LOCK_STATUS   = TRUE
>  #
>  
>  
> -[Rule.ARM.SEC]
> -  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
> -TE  TEAlign = 32$(INF_OUTPUT)/$(MODULE_NAME).efi
> -  }
> -
> -# The AArch64 Vector Table requires a 2K alignment that is not supported by 
> the FDF specification.
> -# It is the reason 4K is used instead of 2K for the module alignment.
>  [Rule.AARCH64.SEC]
> -  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
> -TE  TEAlign = 4K$(INF_OUTPUT)/$(MODULE_NAME).efi
> +  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
> +TE  TEAlign = Auto$(INF_OUTPUT)/$(MODULE_NAME).efi

This does appear to arbitrarily increase indentation of the last entry
on the line by 2, shifting it out of alignment with later entries in
the file?

/
Leif

>}
>  
>  [Rule.Common.PEI_CORE]
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 08/13] Marvell/Armada: Modify GICC alias

[Marcin Wojtas]

Hi Ard,

2017-10-10 16:53 GMT+02:00 Leif Lindholm :
> On Mon, Oct 09, 2017 at 07:00:57PM +0200, Marcin Wojtas wrote:
>> From: Ard Biesheuvel 
>>
>> The GIC architecture mandates that the CPU interface, which consists
>> of 2 consecutive 4 KB frames, can be mapped using separate mappings.
>> Since this is problematic on 64 KB pages, the MMU-400 aliases each
>> frame 16 times, and the two consecutive frames can be found at offset
>> 0xf000. This patch is intended to expose correct GICC alias via
>> MADT, once ACPI support is added.
>
> I'm afraid I don't quite understand this message.
>
> The change seems to be that the InterfaceBase moves from the first 4KB
> alias inside a 64KB page to the last alias within the same page.
> That seems valid, but I don't see how it resolves anything described
> in this message?
>

Can you recall what issue was fixed thanks to this patch?

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

Re: [edk2] [platforms: PATCH 10/13] Marvell/Armada: Switch to unicore PrePi

[Leif Lindholm]

On Mon, Oct 09, 2017 at 07:00:59PM +0200, Marcin Wojtas wrote:
> From: Ard Biesheuvel 
> 
> There is no point in using the MPCore PrePi, given that only the primary
> core will enter UEFI at EL2, and the secondaries will be held in EL3
> until summoned by the OS. So use the unicore flavour instead.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Marvell/Armada/Armada.dsc.inc | 2 +-
>  Platform/Marvell/Armada/Armada70x0.fdf | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
> b/Platform/Marvell/Armada/Armada.dsc.inc
> index b718c60..5a5fde9 100644
> --- a/Platform/Marvell/Armada/Armada.dsc.inc
> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
> @@ -372,7 +372,7 @@
>  [Components.common]
>  
># PEI Phase modules
> -  ArmPlatformPkg/PrePi/PeiMPCore.inf
> +  ArmPlatformPkg/PrePi/PeiUniCore.inf
>  
># DXE
>MdeModulePkg/Core/Dxe/DxeMain.inf {
> diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
> b/Platform/Marvell/Armada/Armada70x0.fdf
> index 999b968..2c3efe0 100644
> --- a/Platform/Marvell/Armada/Armada70x0.fdf
> +++ b/Platform/Marvell/Armada/Armada70x0.fdf
> @@ -199,7 +199,7 @@ READ_STATUS= TRUE
>  READ_LOCK_CAP  = TRUE
>  READ_LOCK_STATUS   = TRUE
>  
> -  INF ArmPlatformPkg/PrePi/PeiMPCore.inf
> +  INF ArmPlatformPkg/PrePi/PeiUniCore.inf
>  
>FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
>  SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED 
> = TRUE {
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 09/13] Marvell/Armada: Disable PerformanceLibrary

[Leif Lindholm]

On Mon, Oct 09, 2017 at 07:00:58PM +0200, Marcin Wojtas wrote:
> From: Ard Biesheuvel 
> 
> Remove the gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask
> setting so it reverts to its default of 0, and disables performance
> profiling.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Marvell/Armada/Armada.dsc.inc | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
> b/Platform/Marvell/Armada/Armada.dsc.inc
> index bd2336f..b718c60 100644
> --- a/Platform/Marvell/Armada/Armada.dsc.inc
> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
> @@ -251,7 +251,6 @@
>gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|100
>gEfiMdePkgTokenSpaceGuid.PcdSpinLockTimeout|1000
>gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue|0xAF
> -  gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|1
>gEfiMdePkgTokenSpaceGuid.PcdPostCodePropertyMask|0
>gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|320
>gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 08/13] Marvell/Armada: Modify GICC alias

[Leif Lindholm]

On Mon, Oct 09, 2017 at 07:00:57PM +0200, Marcin Wojtas wrote:
> From: Ard Biesheuvel 
> 
> The GIC architecture mandates that the CPU interface, which consists
> of 2 consecutive 4 KB frames, can be mapped using separate mappings.
> Since this is problematic on 64 KB pages, the MMU-400 aliases each
> frame 16 times, and the two consecutive frames can be found at offset
> 0xf000. This patch is intended to expose correct GICC alias via
> MADT, once ACPI support is added.

I'm afraid I don't quite understand this message.

The change seems to be that the InterfaceBase moves from the first 4KB
alias inside a 64KB page to the last alias within the same page.
That seems valid, but I don't see how it resolves anything described
in this message?

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Armada/Armada.dsc.inc | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
> b/Platform/Marvell/Armada/Armada.dsc.inc
> index 5071bd5..bd2336f 100644
> --- a/Platform/Marvell/Armada/Armada.dsc.inc
> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
> @@ -263,7 +263,14 @@
>  
># ARM Generic Interrupt Controller
>gArmTokenSpaceGuid.PcdGicDistributorBase|0xF021
> -  gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0xF022
> +
> +  #
> +  # NOTE: the GIC architecture mandates that the CPU interface, which 
> consists
> +  # of 2 consecutive 4 KB frames, can be mapped using separate mappings.
> +  # Since this is problematic on 64 KB pages, the MMU-400 aliases each frame
> +  # 16 times, and the two consecutive frames can be found at offset 0xf000
> +  #
> +  gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0xF022F000
>  
># ARM Architectural Timer Support
>gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|2500
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 04/13] Marvell/Armada: Armada70x0Lib: Clean FV in the D-cache before boot

[Marcin Wojtas]

2017-10-10 16:43 GMT+02:00 Leif Lindholm :
> On Mon, Oct 09, 2017 at 07:00:53PM +0200, Marcin Wojtas wrote:
>> From: Ard Biesheuvel 
>>
>> To prevent cache coherency issues when chainloading via U-Boot, clean
>> and invalidate the FV image in the caches before re-enabling the MMU.
>
> Is this only relevant for chainloading (which is not the expected
> normal usage) or is it also important for warm-reset - for example for
> capsule update (at least from within OS)?

Initially it was done for chainloading purpose - I don't use it
anymore, but just thought the patch itself is worth keeping. About
capsule update - I haven't tried it, it's been not the top priority
for me recently.

>
> If the former, I would prefer for this to be conditionalised, and not
> included by default.

How can we detect, that uefi is being chain-loaded?

>
> If the latter, please update the commit message.
>

I'm considering keeping this patch aside, until it may become
necessary for capsule update, as I cannot guarantee now it's needed at
all. What's your recommendation?

Best regards,
Marcin

> /
> Leif
>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> Signed-off-by: Marcin Wojtas 
>> ---
>>  Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S | 
>> 15 +++
>>  Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf   | 
>>  3 +++
>>  2 files changed, 18 insertions(+)
>>
>> diff --git 
>> a/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S 
>> b/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
>> index 72f8cfc..7544361 100644
>> --- 
>> a/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
>> +++ 
>> b/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
>> @@ -17,6 +17,21 @@
>>
>>  ASM_FUNC(ArmPlatformPeiBootAction)
>>mov   x29, xzr
>> +
>> +  MOV32 (x0, FixedPcdGet64 (PcdFvBaseAddress))
>> +  MOV32 (x3, FixedPcdGet32 (PcdFvSize))
>> +  add   x3, x3, x0
>> +
>> +  mrs   x1, ctr_el0
>> +  and   x1, x1, #0xf  // Dminline
>> +  mov   x2, #4
>> +  lsl   x1, x2, x1// by-VA stride for D-cache maintenance
>> +
>> +0:dccivac, x0
>> +  add   x0, x0, x1
>> +  cmp   x0, x3
>> +  b.lt  0b
>> +
>>ret
>>
>>  //UINTN
>> diff --git a/Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf 
>> b/Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf
>> index 2e198c3..6966683 100644
>> --- a/Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf
>> +++ b/Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf
>> @@ -67,5 +67,8 @@
>>gArmTokenSpaceGuid.PcdArmPrimaryCoreMask
>>gArmTokenSpaceGuid.PcdArmPrimaryCore
>>
>> +  gArmTokenSpaceGuid.PcdFvBaseAddress
>> +  gArmTokenSpaceGuid.PcdFvSize
>> +
>>  [Ppis]
>>gArmMpCoreInfoPpiGuid
>> --
>> 1.8.3.1
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 07/13] Marvell/Armada: Re-enable driver model diagnostics PCDs

[Leif Lindholm]

On Mon, Oct 09, 2017 at 07:00:56PM +0200, Marcin Wojtas wrote:
> From: Ard Biesheuvel 
> 
> For some reason, one of the early ARM platforms disabled all the
> diagnostics related to the UEFI driver model, resulting in the
> output of UEFI shell utilities such as 'devices' or 'drivers' to
> become completely useless. Armada's shared .DSC include file
> inherited this for no good reason, so let's revert it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Marvell/Armada/Armada.dsc.inc | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
> b/Platform/Marvell/Armada/Armada.dsc.inc
> index e920461..5071bd5 100644
> --- a/Platform/Marvell/Armada/Armada.dsc.inc
> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
> @@ -207,10 +207,6 @@
>  
> 
>  
>  [PcdsFeatureFlag.common]
> -  gEfiMdePkgTokenSpaceGuid.PcdComponentNameDisable|TRUE
> -  gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnosticsDisable|TRUE
> -  gEfiMdePkgTokenSpaceGuid.PcdComponentName2Disable|TRUE
> -  gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnostics2Disable|TRUE
>  
>#
># Control what commands are supported from the UI
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 01/13] Marvell/Armada: Introduce platform initialization driver

[Marcin Wojtas]

Hi Leif,

2017-10-10 16:37 GMT+02:00 Leif Lindholm :
> On Mon, Oct 09, 2017 at 07:00:50PM +0200, Marcin Wojtas wrote:
>> In order to enable modification of dynamic PCD's for the libraries
>> and DXE drivers, this patch introduces new driver. It is
>> executed prior to other drivers. Mpp, ComPhy and Utmi libraries
>> initialization were moved from PrePi stage to DXE.
>>
>> To force the correct driver dispatch sequence, introduce a protocol GUID
>> and install the protocol as a NULL protocol when PlatInitDxe executes.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Marcin Wojtas 
>> Signed-off-by: Ard Biesheuvel 
>
> What does Ard's Signed-off-by signify here?
> (I know the authorship on some of these is a bit blurred, since you've
> been working together, but I'd like to be clear.)

These were the lines, introducing/installing protocol GUID stuff. It
was in a small separate patch, but I squashed it into bigger one.

>
>> ---
>>  Platform/Marvell/Armada/Armada.dsc.inc|  3 ++
>>  Platform/Marvell/Armada/Armada70x0.fdf|  5 +++
>>  Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c | 44 
>> 
>>  Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf   | 44 
>> 
>>  Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.c | 11 -
>>  Platform/Marvell/Marvell.dec  |  5 +++
>>  6 files changed, 101 insertions(+), 11 deletions(-)
>>
>> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
>> b/Platform/Marvell/Armada/Armada.dsc.inc
>> index 89fb7e7..417bb0c 100644
>> --- a/Platform/Marvell/Armada/Armada.dsc.inc
>> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
>> @@ -378,6 +378,9 @@
>>ArmPkg/Drivers/TimerDxe/TimerDxe.inf
>>ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
>>
>> +  # Platform Initialization
>> +  Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
>> +
>># Platform drivers
>>Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
>>MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
>> diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
>> b/Platform/Marvell/Armada/Armada70x0.fdf
>> index c861e78..763d76a 100644
>> --- a/Platform/Marvell/Armada/Armada70x0.fdf
>> +++ b/Platform/Marvell/Armada/Armada70x0.fdf
>> @@ -89,6 +89,11 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
>>
>>INF MdeModulePkg/Core/Dxe/DxeMain.inf
>>
>> +  #
>> +  # Platform Initialization
>> +  #
>> +  INF Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
>> +
>># PI DXE Drivers producing Architectural Protocols (EFI Services)
>>INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
>>INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
>> diff --git a/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c 
>> b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c
>> new file mode 100644
>> index 000..919454b
>> --- /dev/null
>> +++ b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c
>> @@ -0,0 +1,44 @@
>> +/** @file
>> +  Copyright (C) Marvell International Ltd. and its affiliates
>
> We normally need a year here as well.
> If Ard has co-authored parts, I guess we should have Linaro copyright
> notice on affected files as well.

I have no problem with that, if you find it appropriate, given my
explanation above.

>
> Content of the patch is fine.
>

Ok, thanks!
Marcin
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 06/13] Marvell/Armada: Switch to generic BDS

[Leif Lindholm]

On Mon, Oct 09, 2017 at 07:00:55PM +0200, Marcin Wojtas wrote:
> From: Ard Biesheuvel 
> 
> Switch from the Intel BDS to the generic BDS, which is preferred for
> ARM platforms given that it is completely legacy free.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Marvell/Armada/Armada.dsc.inc | 19 ---
>  Platform/Marvell/Armada/Armada70x0.fdf |  3 ++-
>  2 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
> b/Platform/Marvell/Armada/Armada.dsc.inc
> index 1b4e713..e920461 100644
> --- a/Platform/Marvell/Armada/Armada.dsc.inc
> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
> @@ -126,8 +126,9 @@
>  
># BDS Libraries
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
> -  
> GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
> -  
> PlatformBdsLib|ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
> +  BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> +  FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> +  
> PlatformBootManagerLib|ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
>  
> @@ -350,6 +351,12 @@
># Shell.
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
>  
> +  # GUID of the generic BDS UiApp
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
> 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
> +
> +  # use the 'TTYTERM' terminal type for optimal compatibility with Linux 
> terminal emulators
> +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
> +
># ARM Pcds
>gArmTokenSpaceGuid.PcdSystemMemoryBase|0
>gArmTokenSpaceGuid.PcdSystemMemorySize|0x4000
> @@ -459,7 +466,13 @@
>MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> -  IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
> +  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
> +  MdeModulePkg/Application/UiApp/UiApp.inf {
> +
> +  NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
> +  NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
> +  
> NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
> +  }
>  
># UEFI application (Shell Embedded Boot Loader)
>ShellPkg/Application/Shell/Shell.inf {
> diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
> b/Platform/Marvell/Armada/Armada70x0.fdf
> index b3d1c60..999b968 100644
> --- a/Platform/Marvell/Armada/Armada70x0.fdf
> +++ b/Platform/Marvell/Armada/Armada70x0.fdf
> @@ -175,7 +175,8 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
>INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> -  INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
> +  INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
> +  INF MdeModulePkg/Application/UiApp/UiApp.inf
>  
>  
>  # PEI phase firmware volume
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 05/13] Marvell/Armada: Use 4k/64k aligned sections for DXE/DXE-rt modules

[Leif Lindholm]

On Mon, Oct 09, 2017 at 07:00:54PM +0200, Marcin Wojtas wrote:
> From: Ard Biesheuvel 
> 
> Enable strict memory protection at boot time and under the OS, by using
> 4 KB section alignment for DXE_DRIVER, UEFI_DRIVER and UEFI_APPLICATION
> modules, and 64 KB alignment for DXE_RUNTIME_DRIVER modules. Note that
> the latter is mandated by the UEFI spec.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Marvell/Armada/Armada.dsc.inc | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
> b/Platform/Marvell/Armada/Armada.dsc.inc
> index 433892e..1b4e713 100644
> --- a/Platform/Marvell/Armada/Armada.dsc.inc
> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
> @@ -486,6 +486,12 @@
>gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
>}
>  
> +[BuildOptions.common.EDKII.DXE_CORE,BuildOptions.common.EDKII.DXE_DRIVER,BuildOptions.common.EDKII.UEFI_DRIVER,BuildOptions.common.EDKII.UEFI_APPLICATION]
> +  GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +
> +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> +  GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1
> +
>  
> 
>  #
>  # Defines - platform description macros
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 04/13] Marvell/Armada: Armada70x0Lib: Clean FV in the D-cache before boot

[Leif Lindholm]

On Mon, Oct 09, 2017 at 07:00:53PM +0200, Marcin Wojtas wrote:
> From: Ard Biesheuvel 
> 
> To prevent cache coherency issues when chainloading via U-Boot, clean
> and invalidate the FV image in the caches before re-enabling the MMU.

Is this only relevant for chainloading (which is not the expected
normal usage) or is it also important for warm-reset - for example for
capsule update (at least from within OS)?

If the former, I would prefer for this to be conditionalised, and not
included by default.

If the latter, please update the commit message.

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S | 
> 15 +++
>  Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf   |  
> 3 +++
>  2 files changed, 18 insertions(+)
> 
> diff --git 
> a/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S 
> b/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
> index 72f8cfc..7544361 100644
> --- 
> a/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
> +++ 
> b/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
> @@ -17,6 +17,21 @@
>  
>  ASM_FUNC(ArmPlatformPeiBootAction)
>mov   x29, xzr
> +
> +  MOV32 (x0, FixedPcdGet64 (PcdFvBaseAddress))
> +  MOV32 (x3, FixedPcdGet32 (PcdFvSize))
> +  add   x3, x3, x0
> +
> +  mrs   x1, ctr_el0
> +  and   x1, x1, #0xf  // Dminline
> +  mov   x2, #4
> +  lsl   x1, x2, x1// by-VA stride for D-cache maintenance
> +
> +0:dccivac, x0
> +  add   x0, x0, x1
> +  cmp   x0, x3
> +  b.lt  0b
> +
>ret
>  
>  //UINTN
> diff --git a/Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf 
> b/Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf
> index 2e198c3..6966683 100644
> --- a/Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf
> +++ b/Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf
> @@ -67,5 +67,8 @@
>gArmTokenSpaceGuid.PcdArmPrimaryCoreMask
>gArmTokenSpaceGuid.PcdArmPrimaryCore
>  
> +  gArmTokenSpaceGuid.PcdFvBaseAddress
> +  gArmTokenSpaceGuid.PcdFvSize
> +
>  [Ppis]
>gArmMpCoreInfoPpiGuid
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 03/13] Marvell/Armada: Armada70x0Lib: Terminate call stack list at entry

[Leif Lindholm]

On Mon, Oct 09, 2017 at 07:00:52PM +0200, Marcin Wojtas wrote:
> From: Ard Biesheuvel 
> 
> To avoid dereferencing junk when walking the call stack in exception
> handlers (which may prevent us from getting a full backtrace), set
> the frame pointer to 0x0 when first entering UEFI.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S | 
> 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S 
> b/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
> index 9265636..72f8cfc 100644
> --- 
> a/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
> +++ 
> b/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
> @@ -16,6 +16,7 @@
>  #include 
>  
>  ASM_FUNC(ArmPlatformPeiBootAction)
> +  mov   x29, xzr
>ret
>  
>  //UINTN
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 02/13] Marvell/Armada: Switch to dynamic PCDs

[Leif Lindholm]

On Mon, Oct 09, 2017 at 07:00:51PM +0200, Marcin Wojtas wrote:
> From: Ard Biesheuvel 
> 
> For full functionality, including HII forms wired to non-volatile UEFI
> variables, we need dynamic PCDs as well. So let's enable those.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Marvell/Armada/Armada.dsc.inc | 10 +++---
>  Platform/Marvell/Armada/Armada70x0.fdf |  1 +
>  2 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
> b/Platform/Marvell/Armada/Armada.dsc.inc
> index 417bb0c..433892e 100644
> --- a/Platform/Marvell/Armada/Armada.dsc.inc
> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
> @@ -67,8 +67,7 @@
>
> UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
>UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
>  
> -  # Assume everything is fixed at build. do not use runtime PCD feature
> -  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
> +  PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>  
>BaseMemoryLib|MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
>  
> @@ -150,6 +149,7 @@
>
> PrePiHobListPointerLib|ArmPlatformPkg/Library/PrePiHobListPointerLib/PrePiHobListPointerLib.inf
>PlatformPeiLib|ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf
>ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
> +  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
>  
>  [LibraryClasses.common.SEC, LibraryClasses.common.PEIM]
>MemoryInitPeiLib|ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf
> @@ -368,10 +368,14 @@
># DXE
>MdeModulePkg/Core/Dxe/DxeMain.inf {
>  
> -  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
>
> NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32GuidedSectionExtractLib.inf
>}
>  
> +  MdeModulePkg/Universal/PCD/Dxe/Pcd.inf {
> +
> +  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
> +  }
> +
># Architectural Protocols DXE
>ArmPkg/Drivers/CpuDxe/CpuDxe.inf
>ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
> diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
> b/Platform/Marvell/Armada/Armada70x0.fdf
> index 763d76a..b3d1c60 100644
> --- a/Platform/Marvell/Armada/Armada70x0.fdf
> +++ b/Platform/Marvell/Armada/Armada70x0.fdf
> @@ -95,6 +95,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
>INF Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
>  
># PI DXE Drivers producing Architectural Protocols (EFI Services)
> +  INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
>INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
>INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 01/13] Marvell/Armada: Introduce platform initialization driver

[Leif Lindholm]

On Mon, Oct 09, 2017 at 07:00:50PM +0200, Marcin Wojtas wrote:
> In order to enable modification of dynamic PCD's for the libraries
> and DXE drivers, this patch introduces new driver. It is
> executed prior to other drivers. Mpp, ComPhy and Utmi libraries
> initialization were moved from PrePi stage to DXE.
> 
> To force the correct driver dispatch sequence, introduce a protocol GUID
> and install the protocol as a NULL protocol when PlatInitDxe executes.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> Signed-off-by: Ard Biesheuvel 

What does Ard's Signed-off-by signify here?
(I know the authorship on some of these is a bit blurred, since you've
been working together, but I'd like to be clear.)

> ---
>  Platform/Marvell/Armada/Armada.dsc.inc|  3 ++
>  Platform/Marvell/Armada/Armada70x0.fdf|  5 +++
>  Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c | 44 
> 
>  Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf   | 44 
> 
>  Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.c | 11 -
>  Platform/Marvell/Marvell.dec  |  5 +++
>  6 files changed, 101 insertions(+), 11 deletions(-)
> 
> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
> b/Platform/Marvell/Armada/Armada.dsc.inc
> index 89fb7e7..417bb0c 100644
> --- a/Platform/Marvell/Armada/Armada.dsc.inc
> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
> @@ -378,6 +378,9 @@
>ArmPkg/Drivers/TimerDxe/TimerDxe.inf
>ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
>  
> +  # Platform Initialization
> +  Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
> +
># Platform drivers
>Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
>MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
> diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
> b/Platform/Marvell/Armada/Armada70x0.fdf
> index c861e78..763d76a 100644
> --- a/Platform/Marvell/Armada/Armada70x0.fdf
> +++ b/Platform/Marvell/Armada/Armada70x0.fdf
> @@ -89,6 +89,11 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
>  
>INF MdeModulePkg/Core/Dxe/DxeMain.inf
>  
> +  #
> +  # Platform Initialization
> +  #
> +  INF Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
> +
># PI DXE Drivers producing Architectural Protocols (EFI Services)
>INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
>INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
> diff --git a/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c 
> b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c
> new file mode 100644
> index 000..919454b
> --- /dev/null
> +++ b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c
> @@ -0,0 +1,44 @@
> +/** @file
> +  Copyright (C) Marvell International Ltd. and its affiliates

We normally need a year here as well.
If Ard has co-authored parts, I guess we should have Linaro copyright
notice on affected files as well.

Content of the patch is fine.

/
Leif

> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +EFI_STATUS
> +EFIAPI
> +ArmadaPlatInitDxeEntryPoint (
> +  IN EFI_HANDLE ImageHandle,
> +  IN EFI_SYSTEM_TABLE   *SystemTable
> +  )
> +{
> +  EFI_STATUSStatus;
> +
> +  DEBUG ((DEBUG_ERROR, "\nArmada Platform Init\n\n"));
> +
> +  Status = gBS->InstallProtocolInterface (,
> +  ,
> +  EFI_NATIVE_INTERFACE,
> +  NULL);
> +  ASSERT_EFI_ERROR (Status);
> +
> +  MvComPhyInit ();
> +  UtmiPhyInit ();
> +  MppInitialize ();
> +
> +  return EFI_SUCCESS;
> +}
> diff --git a/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf 
> b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
> new file mode 100644
> index 000..29abcaf
> --- /dev/null
> +++ b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
> @@ -0,0 +1,44 @@
> +#/* @file
> +#  Copyright (C) Marvell International Ltd. and its affiliates
> +#
> +#  This program and the accompanying materials
> +#  are licensed and made available under the terms and conditions of the BSD 
> License
> +#  which accompanies this distribution.  The full text of the license may be 
> found at
> +#  http://opensource.org/licenses/bsd-license.php
> +#
> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 

[edk2] [PATCH v4] Ifconfig : Fixed False information about Media State.

[Meenakshi Aggarwal]

Issue : We were setting MediaPresent as TRUE (default) and
not checking return status of NetLibDetectMedia().
NetLibDetectMedia() sets MediaPresent FLAG in case of success
only and dont change flag on error.
So, Media State will display as 'Media Present', in case of
error also.

Fix : Check return value of NetLibDetectMedia(), if error then
print "Media State Unknown"

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: Meenakshi Aggarwal 
---
 ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c 
b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
index 4db07b2..082ab72 100644
--- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
+++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
@@ -576,11 +576,14 @@ IfConfigShowInterfaceInfo (
 //
 // Get Media State.
 //
-NetLibDetectMedia (IfCb->NicHandle, );
-if (!MediaPresent) {
-  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
(STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle, L"Media 
disconnected");
+if (EFI_SUCCESS == NetLibDetectMedia (IfCb->NicHandle, )) {
+  if (!MediaPresent) {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
(STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle, L"Media 
disconnected");
+  } else {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
(STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle, L"Media present");
+  }
 } else {
-  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
(STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle, L"Media present");
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
(STR_IFCONFIG_INFO_MEDIA_STATE), gShellNetwork1HiiHandle, L"Media state 
unknown");
 }
 
 //
-- 
2.7.4

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

Re: [edk2] [PATCH] MdeModulePkg/Variable/RuntimeDxe: delete & lock MOR in the absence of SMM

[Zeng, Star]

Could you help make the code consistent to call VariableServiceSetVariable() 
for the Attributes?
One original for MorLock is using real attributes, the new you added for Mor 
will use 0 attributes.
How about to both use 0 attributes.

Another question, why empty MorLockInitAtEndOfDxe() needs to be implemented in 
TcgMorLockDxe.c and called in VariableDxe.c?


Thanks,
Star
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, October 10, 2017 9:25 PM
To: edk2-devel-01 
Cc: Dong, Eric ; Yao, Jiewen ; Zeng, 
Star 
Subject: [PATCH] MdeModulePkg/Variable/RuntimeDxe: delete & lock MOR in the 
absence of SMM

VariableRuntimeDxe deletes and locks the MorLock variable in
MorLockInit(), with the argument that any protection provided by MorLock
can be circumvented if MorLock can be overwritten by unprivileged code
(i.e., outside of SMM).

Extend the argument and the logic to the MOR variable, which is supposed
to be protected by MorLock.

This change was suggested by Star; it is inspired by earlier VariableSmm
commit fda8f631edbb ("MdeModulePkg/Variable/RuntimeDxe: delete and lock
OS-created MOR variable", 2017-10-03).

Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Star Zeng 
Suggested-by: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
Repo:   https://github.com/lersek/edk2.git
Branch: del_and_lock_mor_without_smm

 MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c | 24 

 1 file changed, 24 insertions(+)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
index 7142e2da2073..1610c7aa0706 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
@@ -69,29 +69,53 @@ EFI_STATUS
 MorLockInit (
   VOID
   )
 {
   //
   // Always clear variable to report unsupported to OS.
   // The reason is that the DXE version is not proper to provide *protection*.
   // BIOS should use SMM version variable driver to provide such capability.
   //
   VariableServiceSetVariable (
 MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME,
 ,
 EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS,
 0,
 NULL
 );
 
   //
   // Need set this variable to be read-only to prevent other module set it.
   //
   VariableLockRequestToLock (, 
MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME, 
);
+
+  //
+  // The MOR variable can effectively improve platform security only when the
+  // MorLock variable protects the MOR variable. In turn MorLock cannot be made
+  // secure without SMM support in the platform firmware (see above).
+  //
+  // Thus, delete the MOR variable, should it exist for any reason (some OSes
+  // are known to create MOR unintentionally, in an attempt to set it), then
+  // also lock the MOR variable, in order to prevent other modules from
+  // creating it.
+  //
+  VariableServiceSetVariable (
+MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
+,
+0,  // Attributes
+0,  // DataSize
+NULL// Data
+);
+  VariableLockRequestToLock (
+,
+MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
+
+);
+
   return EFI_SUCCESS;
 }
 
 /**
   Delayed initialization for MOR Control Lock at EndOfDxe.
 
   This function performs any operations queued by MorLockInit().
 **/
-- 
2.14.1.3.gb7cf6e02401b

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

Re: [edk2] [PATCH v2] TFTP : tftp fix for full volume case

[Meenakshi Aggarwal]

Hi,


Kindly apply this patch on edk2 if all reviews are done.


Thanks & Regards,
Meenakshi

> -Original Message-
> From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
> Sent: Tuesday, October 10, 2017 10:52 AM
> To: Carsey, Jaben ; Meenakshi Aggarwal
> ; Fu, Siyuan ; edk2-
> de...@lists.01.org; Ye, Ting 
> Subject: RE: [PATCH v2] TFTP : tftp fix for full volume case
> 
> Reviewed-by: Ruiyu Ni 
> 
> Thanks/Ray
> 
> > -Original Message-
> > From: Carsey, Jaben
> > Sent: Monday, October 9, 2017 10:13 PM
> > To: Meenakshi Aggarwal ; Fu, Siyuan
> > ; edk2-devel@lists.01.org; Ni, Ruiyu
> > ; Ye, Ting 
> > Subject: RE: [PATCH v2] TFTP : tftp fix for full volume case
> >
> > I am fine. Ray?
> >
> > Reviewed-by: Jaben Carsey 
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > Of Meenakshi Aggarwal
> > > Sent: Sunday, October 08, 2017 11:28 PM
> > > To: Fu, Siyuan ; edk2-devel@lists.01.org; Ni,
> > > Ruiyu ; Carsey, Jaben ;
> > > Ye, Ting 
> > > Subject: Re: [edk2] [PATCH v2] TFTP : tftp fix for full volume case
> > > Importance: High
> > >
> > > Hi Team,
> > >
> > >
> > > Any further comments on this patch?
> > >
> > > Or is it ready to merge in edk2?
> > >
> > >
> > > Thanks,
> > > Meenakshi
> > >
> > > > -Original Message-
> > > > From: Meenakshi Aggarwal
> > > > Sent: Wednesday, September 27, 2017 9:01 AM
> > > > To: 'Fu, Siyuan' ; edk2-devel@lists.01.org;
> > > > Ni, Ruiyu ; Carsey, Jaben
> > > > ; Ye, Ting 
> > > > Cc: Udit Kumar ; Vabhav Sharma
> > > > 
> > > > Subject: RE: [PATCH v2] TFTP : tftp fix for full volume case
> > > >
> > > > Hi,
> > > >
> > > > Thanks for the review Siyuan.
> > > >
> > > >
> > > > Ting,
> > > >
> > > > Any comment from your side?
> > > >
> > > > Thanks,
> > > > Meenakshi
> > > >
> > > > > -Original Message-
> > > > > From: Fu, Siyuan [mailto:siyuan...@intel.com]
> > > > > Sent: Tuesday, September 26, 2017 6:12 AM
> > > > > To: Meenakshi Aggarwal ; edk2-
> > > > > de...@lists.01.org; Ni, Ruiyu ; Carsey,
> > > > > Jaben 
> > > > > Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Ye,
> > > > > Ting ; Udit Kumar ;
> > > > > Vabhav
> > > Sharma
> > > > > 
> > > > > Subject: RE: [PATCH v2] TFTP : tftp fix for full volume case
> > > > >
> > > > > Reviewed-by: Fu Siyuan 
> > > > >
> > > > > -Original Message-
> > > > > From: Meenakshi Aggarwal [mailto:meenakshi.aggar...@nxp.com]
> > > > > Sent: Monday, September 25, 2017 11:06 PM
> > > > > To: edk2-devel@lists.01.org; Ni, Ruiyu ;
> > > > > Carsey, Jaben 
> > > > > Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Fu,
> > > > > Siyuan ; Ye, Ting ;
> > > > > Meenakshi Aggarwal ; Udit Kumar
> > > > > ; Vabhav Sharma
> 
> > > > > Subject: [PATCH v2] TFTP : tftp fix for full volume case
> > > > >
> > > > > Issue :
> > > > > When storage media is full, tftp was resulting in ASSERT
> > > > > MdeModulePkg/Core/Dxe/Mem/Page.c, because number of pages
> was
> > > > zero.
> > > > >
> > > > > Reason:
> > > > > While doing tftp, function call ShellWriteFile was modifying
> > > > > FileSize
> > > variable.
> > > > > In case of full disk it was coming out to be Zero.
> > > > >
> > > > > Fix:
> > > > > Storage the original filesize in local variable, and use this
> > > > > variable while freeing the pages.
> > > > >
> > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > Signed-off-by: Udit Kumar 
> > > > > Signed-off-by: Meenakshi Aggarwal
> 
> > > > > Signed-off-by: Vabhav Sharma 
> > > > > Signed-off-by: Meenakshi Aggarwal
> 
> > > > > ---
> > > > >  ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c | 5 -
> > > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > > > b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > > > index 5c50797..fbde3bf 100755
> > > > > --- a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > > > +++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > > > @@ -284,6 +284,7 @@ ShellCommandRunTftp (
> > > > >EFI_HANDLE  Mtftp4ChildHandle;
> > > > >

Re: [edk2] [PATCH v2 1/2] SecurityPkg: make PcdOptionRomImageVerificationPolicy dynamic

[Yao, Jiewen]

I am OK on this patch.

Reviewed-by: jiewen@intel.com

BTW: Do you also need update PcdRemovableMediaImageVerificationPolicy and 
PcdFixedMediaImageVerificationPolicy?


Thank you
Yao Jiewen


From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, October 10, 2017 7:28 PM
To: Long, Qin ; Yao, Jiewen 
Cc: Brijesh Singh ; edk2-devel@lists.01.org; Justen, 
Jordan L ; Tom Lendacky ; 
Zhang, Chao B 
Subject: Re: [edk2] [PATCH v2 1/2] SecurityPkg: make 
PcdOptionRomImageVerificationPolicy dynamic

Jiewen, Qin,

can you guys perhaps help with reviewing this patch? (The second patch
in the series is for OvmfPkg, and it depends on this one.)

Thanks!
Laszlo

On 10/05/17 22:16, Brijesh Singh wrote:
> By default the image verification policy for option ROM images is 0x4
> (DENY_EXECUTE_ON_SECURITY_VIOLATION) but the following OvmfPkg commit:
>
> 1fea9ddb4e3f OvmfPkg: execute option ROM images regardless of Secure Boot
>
> set it to 0x0 (ALWAYS_EXECUTE). This is fine because typically option
> ROMs comes from host-side and most of the time cloud provider (i.e
> hypervisor) have full access over a guest anyway. But when secure boot
> is enabled, we would like to deny the execution of option ROM when
> SEV is active. Having dynamic Pcd will give us flexibility to set the
> security policy at the runtime.
>
> Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=728
> Cc: Chao Zhang >
> Cc: Jordan Justen 
> >
> Cc: Laszlo Ersek >
> Cc: Tom Lendacky >
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> >
> ---
>
> Changes since v1:
>  * Add Contributed-under tag
>
>  SecurityPkg/SecurityPkg.dec | 24 ++--
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/SecurityPkg/SecurityPkg.dec b/SecurityPkg/SecurityPkg.dec
> index 01bff01ed50a..4e32d172d7d9 100644
> --- a/SecurityPkg/SecurityPkg.dec
> +++ b/SecurityPkg/SecurityPkg.dec
> @@ -230,18 +230,6 @@ [Ppis]
>  #
>
>  [PcdsFixedAtBuild, PcdsPatchableInModule]
> -  ## Image verification policy for OptionRom. Only following values are 
> valid:
> -  #  NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification 
> and has been removed.
> -  #  0x  Always trust the image.
> -  #  0x0001  Never trust the image.
> -  #  0x0002  Allow execution when there is security violation.
> -  #  0x0003  Defer execution when there is security violation.
> -  #  0x0004  Deny execution when there is security violation.
> -  #  0x0005  Query user when there is security violation.
> -  # @Prompt Set policy for the image from OptionRom.
> -  # @ValidRange 0x8001 | 0x - 0x0005
> -  
> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04|UINT32|0x0001
> -
>## Image verification policy for removable media which includes CD-ROM, 
> Floppy, USB and network.
>#  Only following values are valid:
>#  NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification 
> and has been removed.
> @@ -304,6 +292,18 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
>
> gEfiSecurityPkgTokenSpaceGuid.PcdStatusCodeSubClassTpmDevice|0x010D|UINT32|0x0007
>
>  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> +  ## Image verification policy for OptionRom. Only following values are 
> valid:
> +  #  NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification 
> and has been removed.
> +  #  0x  Always trust the image.
> +  #  0x0001  Never trust the image.
> +  #  0x0002  Allow execution when there is security violation.
> +  #  0x0003  Defer execution when there is security violation.
> +  #  0x0004  Deny execution when there is security violation.
> +  #  0x0005  Query user when there is security violation.
> +  # @Prompt Set policy for the image from OptionRom.
> +  # @ValidRange 0x8001 | 0x - 0x0005
> +  
> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04|UINT32|0x0001
> +
>## Indicates the presence or absence of the platform operator during 
> firmware booting.
>#  If platform operator is not physical presence during boot. TPM will be 
> locked and the TPM commands
>#  that required operator physical presence can not run.
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg/Variable/RuntimeDxe: delete & lock MOR in the absence of SMM

[Laszlo Ersek]

VariableRuntimeDxe deletes and locks the MorLock variable in
MorLockInit(), with the argument that any protection provided by MorLock
can be circumvented if MorLock can be overwritten by unprivileged code
(i.e., outside of SMM).

Extend the argument and the logic to the MOR variable, which is supposed
to be protected by MorLock.

This change was suggested by Star; it is inspired by earlier VariableSmm
commit fda8f631edbb ("MdeModulePkg/Variable/RuntimeDxe: delete and lock
OS-created MOR variable", 2017-10-03).

Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Star Zeng 
Suggested-by: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
Repo:   https://github.com/lersek/edk2.git
Branch: del_and_lock_mor_without_smm

 MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c | 24 

 1 file changed, 24 insertions(+)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
index 7142e2da2073..1610c7aa0706 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
@@ -69,29 +69,53 @@ EFI_STATUS
 MorLockInit (
   VOID
   )
 {
   //
   // Always clear variable to report unsupported to OS.
   // The reason is that the DXE version is not proper to provide *protection*.
   // BIOS should use SMM version variable driver to provide such capability.
   //
   VariableServiceSetVariable (
 MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME,
 ,
 EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS,
 0,
 NULL
 );
 
   //
   // Need set this variable to be read-only to prevent other module set it.
   //
   VariableLockRequestToLock (, 
MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME, 
);
+
+  //
+  // The MOR variable can effectively improve platform security only when the
+  // MorLock variable protects the MOR variable. In turn MorLock cannot be made
+  // secure without SMM support in the platform firmware (see above).
+  //
+  // Thus, delete the MOR variable, should it exist for any reason (some OSes
+  // are known to create MOR unintentionally, in an attempt to set it), then
+  // also lock the MOR variable, in order to prevent other modules from
+  // creating it.
+  //
+  VariableServiceSetVariable (
+MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
+,
+0,  // Attributes
+0,  // DataSize
+NULL// Data
+);
+  VariableLockRequestToLock (
+,
+MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
+
+);
+
   return EFI_SUCCESS;
 }
 
 /**
   Delayed initialization for MOR Control Lock at EndOfDxe.
 
   This function performs any operations queued by MorLockInit().
 **/
-- 
2.14.1.3.gb7cf6e02401b

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

Re: [edk2] [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable

[Zeng, Star]

I agree with this direction a) if we think MOR with non-SMM is useless.

Thanks,
Star
From: Yao, Jiewen
Sent: Tuesday, October 10, 2017 12:15 PM
To: Laszlo Ersek ; Zeng, Star ; 
edk2-devel-01 
Cc: Dong, Eric 
Subject: RE: [edk2] [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and 
lock OS-created MOR variable

Yes, option a) looks good to me. A simple patch is good enough in this case.

In addition, this original patch passed our validation with MOR and MORL.
The series is reviewed-by: jiewen@intel.com

We can treat a) in another patch.

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Monday, October 9, 2017 11:21 PM
To: Zeng, Star >; edk2-devel-01 
>
Cc: Yao, Jiewen >; Dong, Eric 
>
Subject: Re: [edk2] [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and 
lock OS-created MOR variable

On 10/09/17 09:12, Zeng, Star wrote:
> Laszlo,
>
> Do you think VariableRuntimeDxe(TcgMorLockDxe.c) also needs to delete and 
> lock OS-created MOR variable?

Maybe -- I'm not sure.

If an edk2 platform uses "VariableRuntimeDxe", then it cannot securely
support MorLock, that's for sure. However, the same platform might still
support plain MOR.

How can we determine if the platform wants to support MOR? Should we
again look for the presence of the TCG / TCG2 protocols? I cannot tell
if TcgMor.inf, and other modules under SecurityPkg, intend to support a
"no-SMM" configuration.

So I can only give you a conditional answer:

(a) If an edk2 platform can *never* sensibly support plain MOR without
SMM, then yes, we should delete and lock the MOR variable in
"TcgMorLockDxe.c", function MorLockInit().

(b) If an edk2 platform *may* opt to support plain MOR (but not MorLock)
without SMM, then we should apply the same End-of-Dxe trick as in the
SMM case. This is however quite a bit of development and I suggest that
we postpone it -- file a BZ about it -- until an edk2 platform actually
needs this. (It looks like a quite unlikely use case though: MOR is a
security feature that is not really secure without MorLock, and MorLock
is insecure without SMM. So one might reason that MOR-without-SMM is
useless.)

(c) We can also say "we don't care", because, technically speaking, no
inconsistency between the MOR and MorLock variables can be created in
the "no-SMM" case (because it is never possible to create MorLock
without MOR -- since creating MorLock is prevented already).

So, I don't know. If Jiewen thinks that "MOR without SMM" is useless
(because it is inherently insecure --> option (a)), I can append a small
patch #7, in order to delete and lock MOR too, in MorLockInit()
[TcgMorLockDxe.c].


Here's another idea: if the "no SMM" case requires extra thinking and
regression testing (i.e. the patch would be more complex than simple MOR
deletion + locking) , can we go ahead with this series for now, and file
a TianoCore BZ about the "no SMM" case? (I should say in advance that
I'm not volunteering to address the "no SMM" Bugzilla any time soon; I
don't know much (yet) about the TCG modules in SecurityPkg, and I think
I won't have time for the investigation in the next weeks.)

Jiewen, what do you say?

Thanks!
Laszlo

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, October 4, 2017 5:29 AM
> To: edk2-devel-01 >
> Cc: Dong, Eric >; Yao, Jiewen 
> >; Ladi Prosek 
> >; Zeng, Star 
> >
> Subject: [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock 
> OS-created MOR variable
>
> According to the TCG Platform Reset Attack Mitigation Specification (May 15, 
> 2008):
>
>> 5 Interface for UEFI
>> 5.1 UEFI Variable
>> 5.1.1 The MemoryOverwriteRequestControl
>>
>> Start of informative comment:
>>
>> [...] The OS loader should not create the variable. Rather, the
>> firmware is required to create it and must support the semantics described 
>> here.
>>
>> End of informative comment.
>
> However, some OS kernels create the MOR variable even if the platform 
> firmware does not support it (see one Bugzilla reference below). This OS 
> issue breaks the logic added in the last patch.
>
> Strengthen the MOR check by searching for the TCG or TCG2 protocols, as 
> edk2's implementation of MOR depends on (one of) those protocols.
>
> The protocols are defined under MdePkg, thus there's no inter-package 
> dependency issue. In addition, calling UEFI services in
> 

Re: [edk2] [PATCH] MdeModulePkg/Bds: Remove assertion in BmCharToUint

[Zeng, Star]

Reviewed-by: Star Zeng 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Tuesday, October 10, 2017 4:40 PM
To: edk2-devel@lists.01.org
Cc: Laszlo Ersek ; Ard Biesheuvel 
Subject: [edk2] [PATCH] MdeModulePkg/Bds: Remove assertion in BmCharToUint

BmCharToUint() could be called using external data and it already contains 
logic to return -1 when data is invalid, so removing unnecessary assertion to 
avoid system hang.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Ard Biesheuvel 
Cc: Laszlo Ersek 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
index 11ab86792a..a3fa254245 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
@@ -420,7 +420,6 @@ BmCharToUint (
 return (Char - L'A' + 0xA);
   }
 
-  ASSERT (FALSE);
   return (UINTN) -1;
 }
 
--
2.12.2.windows.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 0/6] MdeModulePkg/VariableSmm: fix MOR / MorLock inconsistency

[Zeng, Star]

Good to see the series pushed.

Thanks,
Star
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, October 10, 2017 6:09 PM
To: Yao, Jiewen ; Zeng, Star 
Cc: edk2-devel-01 ; Dong, Eric ; 
Ladi Prosek 
Subject: Re: [edk2] [PATCH 0/6] MdeModulePkg/VariableSmm: fix MOR / MorLock 
inconsistency

On 10/10/17 06:17, Yao, Jiewen wrote:
> Thanks.
> Please use ASSERT() when you check in.
>
> Series Reviewed-by: jiewen@intel.com

Thank you all for the (quick!) feedback; I've pushed the series:
35ac962b5473..fda8f631edbb.

Here's the cumulative diff between the posted (v1) and the pushed series, based 
on the comments:

> diff --git 
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h 
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> index 759e47db7f29..b98b8556a23a 100644
> --- 
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.
> +++ h
> @@ -62,9 +62,7 @@ MorLockInitAtEndOfDxe (
>@param[in]  VariableName the name of the vendor's variable, as a
> Null-Terminated Unicode String
>@param[in]  VendorGuid   Unify identifier for vendor.
> -  @param[in]  Attributes   Point to memory location to return the attributes 
> of
> -   variable. If the point is NULL, the parameter 
> would
> -   be ignored.
> +  @param[in]  Attributes   Attributes bitmask to set for the variable.
>@param[in]  DataSize The size in bytes of Data-Buffer.
>@param[in]  Data Point to the content of the variable.
>
> diff --git 
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c 
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
> index a91fc42ff465..7142e2da2073 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
> @@ -31,9 +31,7 @@ extern EDKII_VARIABLE_LOCK_PROTOCOL mVariableLock;
>@param[in]  VariableName the name of the vendor's variable, as a
> Null-Terminated Unicode String
>@param[in]  VendorGuid   Unify identifier for vendor.
> -  @param[in]  Attributes   Point to memory location to return the attributes 
> of
> -   variable. If the point is NULL, the parameter 
> would
> -   be ignored.
> +  @param[in]  Attributes   Attributes bitmask to set for the variable.
>@param[in]  DataSize The size in bytes of Data-Buffer.
>@param[in]  Data Point to the content of the variable.
>
> diff --git 
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c 
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> index 0a0281e44bc1..93a300a84677 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> @@ -319,9 +319,7 @@ SetVariableCheckHandlerMorLock (
>@param[in]  VariableName the name of the vendor's variable, as a
> Null-Terminated Unicode String
>@param[in]  VendorGuid   Unify identifier for vendor.
> -  @param[in]  Attributes   Point to memory location to return the attributes 
> of
> -   variable. If the point is NULL, the parameter 
> would
> -   be ignored.
> +  @param[in]  Attributes   Attributes bitmask to set for the variable.
>@param[in]  DataSize The size in bytes of Data-Buffer.
>@param[in]  Data Point to the content of the variable.
>
> @@ -427,8 +425,9 @@ MorLockInitAtEndOfDxe (
>if (!mMorLockInitializationRequired) {
>  //
>  // The EFI_SMM_FAULT_TOLERANT_WRITE_PROTOCOL has never been installed, 
> thus
> -// the variable write service is unavailable. Do nothing.
> +// the variable write service is unavailable. This should never happen.
>  //
> +ASSERT (FALSE);
>  return;
>}
>

In addition, I modified the commit message of patch #2 (now commit 
03877377e326, "MdeModulePkg/Variable/RuntimeDxe: move MOR func.
declarations to header", 2017-09-30), to credit Star for the fixed "Attributes" 
param description.

(The ASSERT from Jiewen needed no commit message update; commit 7516532f9c2d 
("MdeModulePkg/Variable/RuntimeDxe: delay MorLock creation until EndOfDxe", 
2017-09-30) already carried "Suggested-by: Jiewen Yao
".)


I plan to post the separate patch for option (a) soon (see 
<74D8A39837DF1E4DA445A8C0B3885C503A9D71F4@shsmsx102.ccr.corp.intel.com">http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503A9D71F4@shsmsx102.ccr.corp.intel.com>).

Thank you!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org

Re: [edk2] [PATCH v2 1/2] SecurityPkg: make PcdOptionRomImageVerificationPolicy dynamic

[Laszlo Ersek]

Jiewen, Qin,

can you guys perhaps help with reviewing this patch? (The second patch
in the series is for OvmfPkg, and it depends on this one.)

Thanks!
Laszlo

On 10/05/17 22:16, Brijesh Singh wrote:
> By default the image verification policy for option ROM images is 0x4
> (DENY_EXECUTE_ON_SECURITY_VIOLATION) but the following OvmfPkg commit:
> 
> 1fea9ddb4e3f OvmfPkg: execute option ROM images regardless of Secure Boot
> 
> set it to 0x0 (ALWAYS_EXECUTE). This is fine because typically option
> ROMs comes from host-side and most of the time cloud provider (i.e
> hypervisor) have full access over a guest anyway. But when secure boot
> is enabled, we would like to deny the execution of option ROM when
> SEV is active. Having dynamic Pcd will give us flexibility to set the
> security policy at the runtime.
> 
> Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=728
> Cc: Chao Zhang 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Tom Lendacky 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
> 
> Changes since v1:
>  * Add Contributed-under tag
> 
>  SecurityPkg/SecurityPkg.dec | 24 ++--
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/SecurityPkg/SecurityPkg.dec b/SecurityPkg/SecurityPkg.dec
> index 01bff01ed50a..4e32d172d7d9 100644
> --- a/SecurityPkg/SecurityPkg.dec
> +++ b/SecurityPkg/SecurityPkg.dec
> @@ -230,18 +230,6 @@ [Ppis]
>  #
>  
>  [PcdsFixedAtBuild, PcdsPatchableInModule]
> -  ## Image verification policy for OptionRom. Only following values are 
> valid:
> -  #  NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification 
> and has been removed.
> -  #  0x  Always trust the image.
> -  #  0x0001  Never trust the image.
> -  #  0x0002  Allow execution when there is security violation.
> -  #  0x0003  Defer execution when there is security violation.
> -  #  0x0004  Deny execution when there is security violation.
> -  #  0x0005  Query user when there is security violation.
> -  # @Prompt Set policy for the image from OptionRom.
> -  # @ValidRange 0x8001 | 0x - 0x0005
> -  
> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04|UINT32|0x0001
> -
>## Image verification policy for removable media which includes CD-ROM, 
> Floppy, USB and network.
>#  Only following values are valid:
>#  NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification 
> and has been removed.
> @@ -304,6 +292,18 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
>
> gEfiSecurityPkgTokenSpaceGuid.PcdStatusCodeSubClassTpmDevice|0x010D|UINT32|0x0007
>  
>  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> +  ## Image verification policy for OptionRom. Only following values are 
> valid:
> +  #  NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification 
> and has been removed.
> +  #  0x  Always trust the image.
> +  #  0x0001  Never trust the image.
> +  #  0x0002  Allow execution when there is security violation.
> +  #  0x0003  Defer execution when there is security violation.
> +  #  0x0004  Deny execution when there is security violation.
> +  #  0x0005  Query user when there is security violation.
> +  # @Prompt Set policy for the image from OptionRom.
> +  # @ValidRange 0x8001 | 0x - 0x0005
> +  
> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04|UINT32|0x0001
> +
>## Indicates the presence or absence of the platform operator during 
> firmware booting.
>#  If platform operator is not physical presence during boot. TPM will be 
> locked and the TPM commands 
>#  that required operator physical presence can not run.
> 

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

Re: [edk2] [PATCH 0/6] MdeModulePkg/VariableSmm: fix MOR / MorLock inconsistency

[Laszlo Ersek]

On 10/10/17 06:17, Yao, Jiewen wrote:
> Thanks.
> Please use ASSERT() when you check in.
>
> Series Reviewed-by: jiewen@intel.com

Thank you all for the (quick!) feedback; I've pushed the series:
35ac962b5473..fda8f631edbb.

Here's the cumulative diff between the posted (v1) and the pushed
series, based on the comments:

> diff --git 
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h 
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> index 759e47db7f29..b98b8556a23a 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> @@ -62,9 +62,7 @@ MorLockInitAtEndOfDxe (
>@param[in]  VariableName the name of the vendor's variable, as a
> Null-Terminated Unicode String
>@param[in]  VendorGuid   Unify identifier for vendor.
> -  @param[in]  Attributes   Point to memory location to return the attributes 
> of
> -   variable. If the point is NULL, the parameter 
> would
> -   be ignored.
> +  @param[in]  Attributes   Attributes bitmask to set for the variable.
>@param[in]  DataSize The size in bytes of Data-Buffer.
>@param[in]  Data Point to the content of the variable.
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c 
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
> index a91fc42ff465..7142e2da2073 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
> @@ -31,9 +31,7 @@ extern EDKII_VARIABLE_LOCK_PROTOCOL mVariableLock;
>@param[in]  VariableName the name of the vendor's variable, as a
> Null-Terminated Unicode String
>@param[in]  VendorGuid   Unify identifier for vendor.
> -  @param[in]  Attributes   Point to memory location to return the attributes 
> of
> -   variable. If the point is NULL, the parameter 
> would
> -   be ignored.
> +  @param[in]  Attributes   Attributes bitmask to set for the variable.
>@param[in]  DataSize The size in bytes of Data-Buffer.
>@param[in]  Data Point to the content of the variable.
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c 
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> index 0a0281e44bc1..93a300a84677 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> @@ -319,9 +319,7 @@ SetVariableCheckHandlerMorLock (
>@param[in]  VariableName the name of the vendor's variable, as a
> Null-Terminated Unicode String
>@param[in]  VendorGuid   Unify identifier for vendor.
> -  @param[in]  Attributes   Point to memory location to return the attributes 
> of
> -   variable. If the point is NULL, the parameter 
> would
> -   be ignored.
> +  @param[in]  Attributes   Attributes bitmask to set for the variable.
>@param[in]  DataSize The size in bytes of Data-Buffer.
>@param[in]  Data Point to the content of the variable.
>
> @@ -427,8 +425,9 @@ MorLockInitAtEndOfDxe (
>if (!mMorLockInitializationRequired) {
>  //
>  // The EFI_SMM_FAULT_TOLERANT_WRITE_PROTOCOL has never been installed, 
> thus
> -// the variable write service is unavailable. Do nothing.
> +// the variable write service is unavailable. This should never happen.
>  //
> +ASSERT (FALSE);
>  return;
>}
>

In addition, I modified the commit message of patch #2 (now commit
03877377e326, "MdeModulePkg/Variable/RuntimeDxe: move MOR func.
declarations to header", 2017-09-30), to credit Star for the fixed
"Attributes" param description.

(The ASSERT from Jiewen needed no commit message update; commit
7516532f9c2d ("MdeModulePkg/Variable/RuntimeDxe: delay MorLock creation
until EndOfDxe", 2017-09-30) already carried "Suggested-by: Jiewen Yao
".)


I plan to post the separate patch for option (a) soon (see
<74D8A39837DF1E4DA445A8C0B3885C503A9D71F4@shsmsx102.ccr.corp.intel.com">http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503A9D71F4@shsmsx102.ccr.corp.intel.com>).

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

[edk2] [Patch] SourceLevelDebugPkg: Update SmmDebugAgentLib to restore APIC timer

[Liming Gao]

In enter SMI, APIC timer may be initialized. After exit SMI, APIC timer
will be restore.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao 
Cc: Ruiyu Ni 
---
 .../DebugAgent/SmmDebugAgent/SmmDebugAgentLib.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git 
a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgent/SmmDebugAgentLib.c 
b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgent/SmmDebugAgentLib.c
index 11afd32..6be8c54 100644
--- a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgent/SmmDebugAgentLib.c
+++ b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgent/SmmDebugAgentLib.c
@@ -20,6 +20,11 @@ UINTN   mSavedDebugRegisters[6];
 IA32_IDT_GATE_DESCRIPTORmIdtEntryTable[33];
 BOOLEAN mSkipBreakpoint = FALSE;
 BOOLEAN mSmmDebugIdtInitFlag = FALSE;
+BOOLEAN mApicTimerRestore = FALSE;
+BOOLEAN mPeriodicMode;
+UINT32  mTimerCycle;
+UINTN   mApicTimerDivisor;
+UINT8   mVector;
 
 CHAR8 mWarningMsgIgnoreSmmEntryBreak[] = "Ignore smmentrybreak setting for SMI 
issued during DXE debugging!\r\n";
 
@@ -191,8 +196,6 @@ InitializeDebugAgent (
   DEBUG_AGENT_MAILBOX   *Mailbox;
   UINT64*MailboxLocation;
   UINT32DebugTimerFrequency;
-  BOOLEAN   PeriodicMode;
-  UINTN TimerCycle;
 
   switch (InitFlag) {
   case DEBUG_AGENT_INIT_SMM:
@@ -289,9 +292,10 @@ InitializeDebugAgent (
 // Check if CPU APIC Timer is working, otherwise initialize it.
 //
 InitializeLocalApicSoftwareEnable (TRUE);
-GetApicTimerState (NULL, , NULL);
-TimerCycle = GetApicTimerInitCount ();
-if (!PeriodicMode || TimerCycle == 0) {
+GetApicTimerState (, , );
+mTimerCycle = GetApicTimerInitCount ();
+if (!mPeriodicMode || mTimerCycle == 0) {
+  mApicTimerRestore = TRUE;
   InitializeDebugTimer (NULL, FALSE);
 }
 Mailbox = GetMailboxPointer ();
@@ -327,6 +331,13 @@ InitializeDebugAgent (
 //
 mSkipBreakpoint = FALSE;
 RestoreDebugRegister ();
+//
+// Restore APIC Timer
+//
+if (mApicTimerRestore) {
+  InitializeApicTimer (mApicTimerDivisor, mTimerCycle, mPeriodicMode, 
mVector);
+  mApicTimerRestore = FALSE;
+}
 break;
 
   case DEBUG_AGENT_INIT_THUNK_PEI_IA32TOX64:
-- 
2.8.0.windows.1

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

Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: don't ASSERT on 'BootNext' varname

[Ni, Ruiyu]

All,
I just sent out two patches. One to remove the assertion, the other to fix a 
bug in EfiBootManagerIsValidLoadOptionVariableName.

Thanks/Ray

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, October 5, 2017 5:08 PM
> To: Laszlo Ersek 
> Cc: Zeng, Star ; Ard Biesheuvel
> ; Ni, Ruiyu ; Dong, Eric
> ; edk2-devel@lists.01.org; leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: don't ASSERT
> on 'BootNext' varname
> 
> Thank you star.
> 
> I ack this update.
> 
> I recall we did a review for bds on variable usage and assert usage and fixed 
> such
> issue. If this is a regression, we probable need review again.
> 
> thank you!
> Yao, Jiewen
> 
> 
> > 在 2017年10月5日，下午3:59，Laszlo Ersek  写道：
> >
> >> On 10/05/17 09:31, Zeng, Star wrote:
> >> I got your point.
> >> From literal meaning of the API, I agree the ASSERT should be removed.
> >> If the input parameter is assumed to be valid always, the API could be not
> called at all.
> >> If the input parameter is not assumed to be valid always, the API should 
> >> not
> assert.
> >>
> >> I just tried an experiment and can easily reproduce the assert.
> >> 1. Boot NT32 to shell.
> >> 2. Create L"BootNext" variable with shell command: setvar BootNext -NV -RT
> -BS =.
> >> 3. Reboot and then ASSERT.
> >> ASSERT!: [BdsDxe]
> >> i:\git\edk2git\edk2\MdeModulePkg\Library\UefiBootManagerLib\BmMisc.c
> >> (423): ((BOOLEAN)(0==1))
> >>
> >> The calling stack is:
> >> BdsEntry(BdsEntry.c L844) ->
> >>  EfiBootManagerGetLoadOptions(BdsLoadOption.c L1092) ->
> >>BmCollectLoadOptions() with L"BootNext" from the loop in
> BmForEachVariable() ->
> >>  EfiBootManagerIsValidLoadOptionVariableName() ->
> >>BmCharToUint() ->
> >>  ASSERT(FALSE)
> >>
> >> The assert seems new caused by
> 0e6584e38650cef9a6b4579553679c0f12d897bc as L"BootNext" was deleted
> before calling EfiBootManagerGetLoadOptions() when no this commit.
> >
> > Ah, good point!
> >
> > OK, so let's wait until Ray acks the removal of the assert.
> >
> > Thanks!
> > Laszlo
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Wednesday, October 4, 2017 11:06 PM
> >> To: Zeng, Star ; Ard Biesheuvel
> >> 
> >> Cc: Ni, Ruiyu ; Dong, Eric ;
> >> edk2-devel@lists.01.org; leif.lindh...@linaro.org; Yao, Jiewen
> >> 
> >> Subject: Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: don't
> >> ASSERT on 'BootNext' varname
> >>
> >> Star,
> >>
> >>> On 10/04/17 16:09, Zeng, Star wrote:
> >>> Thanks for confirming the urgency.
> >>>
> >>> I have no strong motivation to keep/remove the ASSERT, I would like Ruiyu
> to argue and make the decision.
> >>> I mainly want the issue (the code ends up calling this
> function(EfiBootManagerIsValidLoadOptionVariableName) on L"BootNext")
> could be root caused.
> >>
> >> it might be interesting to find out about the exact call stack.
> >> However, I'd like to point out that the exact purpose of the
> >> EfiBootManagerIsValidLoadOptionVariableName() function is to check
> >> *whether* the variable name is a valid boot option name or not. If
> >> not
> >> -- for whatever reason -- then it shouldn't ASSERT(); it should just return
> FALSE.
> >>
> >> Perhaps it's relevant: the function was made public in commit 
> >> 3dc5c1ae5c757.
> >>
> >> Thanks
> >> Laszlo
> >>
> >>> -Original Message-
> >>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >>> Sent: Wednesday, October 4, 2017 9:54 PM
> >>> To: Zeng, Star 
> >>> Cc: Yao, Jiewen ; Ni, Ruiyu
> >>> ; edk2-devel@lists.01.org; Dong, Eric
> >>> ; leif.lindh...@linaro.org
> >>> Subject: Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: don't
> >>> ASSERT on 'BootNext' varname
> >>>
>  On 4 October 2017 at 14:49, Zeng, Star  wrote:
>  Creating Boot000@ with gEfiGlobalVariableGuid can not succeed as it
>  will be rejected by
>  MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf that will
> check the VariableName against UEFI spec “Table 13. Global Variables”
>  if the VendorGuid is gEfiGlobalVariableGuid.
> 
> 
> 
>  I would suspect there is a bug at other place if the code ends up
>  calling this function(EfiBootManagerIsValidLoadOptionVariableName) on
> L"BootNext".
> 
> >>>
> >>> That still does not mean you should ASSERT() here. The state of the 
> >>> variable
> store != the internals of the code, and so it should be considered external 
> input
> to some extent. ASSERTs are meant to catch programming errors, not errors in
> the varstore image.
> >>>
> >>>
> 
>  Ard,
> 
>  Is the fix urgent or not 

Re: [edk2] [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA Map/Umap bounce buffer

[Ard Biesheuvel]

On 10 October 2017 at 04:41, Daniil Egranov  wrote:
> Hi Ard, Ray,
>
> Thanks for your comments.
>
>
> On 10/09/2017 07:23 AM, Ard Biesheuvel wrote:
>>
>> On 9 October 2017 at 11:40, Ard Biesheuvel 
>> wrote:
>>>
>>> On 9 October 2017 at 08:42, Ni, Ruiyu  wrote:

 The "read"/"write" is from the Bus Master's point of view.


 Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Daniil
> Egranov
> Sent: Monday, October 9, 2017 9:16 AM
> To: edk2-devel@lists.01.org
> Cc: leif.lindh...@linaro.org; Zeng, Star ;
> ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA
> Map/Umap bounce buffer
>
> The patch corrects the logic of transferring data between a bounce
> buffer and a
> real buffer above 4GB:
> 1. In the case of mapping a bounce buffer for the write operation, data
> from a
> real buffer should be copied into a bounce buffer.
> 2.In the case of unmapping a bounce buffer for the read operation, data
> should
> be copied from a bounce buffer into a real buffer.
>
> The patch resolves a Juno board issue with the the grub and SATA
> drives.
>
>>> I am intrigued by this.
>>>
>>> So as I suggested, this has to do with 64-bit DMA, but not in the way
>>> I suspected. UEFI itself never hits this code path, because it runs
>>> entirely < 32 GB, but as soon as GRUB starts allocating loader data
>>> and use it for DMA, the bounce buffering kicks in because apparently,
>>> the SATA controller is not 64-bit DMA capable.
>>>
>>> Are you using the SataSiI3132Dxe driver on Juno? Does this help at all?
>>>
>>> diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
>>> b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
>>> index 2fb5fd68db01..a938563ebdd6 100644
>>> --- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
>>> +++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
>>> @@ -104,7 +104,7 @@ SiI3132AtaPassThruCommand (
>>>   }
>>>
>>>   Status = PciIo->Map (
>>> -   PciIo, EfiPciIoOperationBusMasterRead,
>>> +   PciIo, EfiPciIoOperationBusMasterWrite,
>>>  Packet->InDataBuffer, ,
>>> , 
>>>  );
>>>   if (EFI_ERROR (Status)) {
>>> @@ -139,7 +139,7 @@ SiI3132AtaPassThruCommand (
>>>   OutDataBufferLength = Packet->OutTransferLength *
>>> SataDevice->BlockSize;
>>>
>>>   Status = PciIo->Map (
>>> -   PciIo, EfiPciIoOperationBusMasterWrite,
>>> +   PciIo, EfiPciIoOperationBusMasterRead,
>>>  Packet->OutDataBuffer, ,
>>> , 
>>>  );
>>>   if (EFI_ERROR (Status)) {
>>
>> Also, it might make sense to find out if the hardware is really not
>> 64-bit DMA capable, or whether the driver simply fails to set the
>> EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute.
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>
> Swapping the EfiPciIoOperationBusMasterRead and
> EfiPciIoOperationBusMasterWrite operations in the SiI3132AtaPassThru.c fixes
> the problem as well. The driver's patch will be the correct fix for this
> issue. I think i missed the point what these operations are from the Bus
> Master's perspective.
>

Good!

> The old PciHostBridge Juno driver was using NullDmaLib so it was direct
> mapping. That explains why the SataSiI3132Dxe worked with the original host
> bridge driver and failed with the new one.
>

NullDmaLib has nothing to do with this. The difference between the old
driver and the generic one is that the old driver always enables
64-bit DMA, while the generic one only does so if the driver sets the
EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute. So to fix this
driver, we should
a) fix the swapped constants above
b) set EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE in the Start() hook
c) add code to disable DMA at ExitBootServices() [or the controller
may scribble over RAM when the kernel takes over]
d) replace mbStarted with a per-controller attribute, given that this
is a UEFI driver model implementation that could theoretically drive
multiple hardware instances concurrently.

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

[edk2] [PATCH] MdeModulePkg/Bds: Check variable name even OptionNumber is NULL

[Ruiyu Ni]

Current implementation skips to check whether the last four
characters are digits when the OptionNumber is NULL.
Even worse, it may incorrectly return FALSE when OptionNumber is
NULL.

The patch fixes it to always check the variable name even
OptionNumber is NULL.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Ard Biesheuvel 
Cc: Laszlo Ersek 
---
 .../Library/UefiBootManagerLib/BmLoadOption.c  | 45 ++
 1 file changed, 30 insertions(+), 15 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index b0a35058d0..32918caf32 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -785,6 +785,8 @@ EfiBootManagerIsValidLoadOptionVariableName (
   UINTN VariableNameLen;
   UINTN Index;
   UINTN Uint;
+  EFI_BOOT_MANAGER_LOAD_OPTION_TYPE LocalOptionType;
+  UINT16LocalOptionNumber;
 
   if (VariableName == NULL) {
 return FALSE;
@@ -792,39 +794,52 @@ EfiBootManagerIsValidLoadOptionVariableName (
 
   VariableNameLen = StrLen (VariableName);
 
+  //
+  // Return FALSE when the variable name length is too small.
+  //
   if (VariableNameLen <= 4) {
 return FALSE;
   }
 
-  for (Index = 0; Index < ARRAY_SIZE (mBmLoadOptionName); Index++) {
-if ((VariableNameLen - 4 == StrLen (mBmLoadOptionName[Index])) &&
-(StrnCmp (VariableName, mBmLoadOptionName[Index], VariableNameLen - 4) 
== 0)
+  //
+  // Return FALSE when the variable name doesn't start with 
Driver/SysPrep/Boot/PlatformRecovery.
+  //
+  for (LocalOptionType = 0; LocalOptionType < ARRAY_SIZE (mBmLoadOptionName); 
LocalOptionType++) {
+if ((VariableNameLen - 4 == StrLen (mBmLoadOptionName[LocalOptionType])) &&
+(StrnCmp (VariableName, mBmLoadOptionName[LocalOptionType], 
VariableNameLen - 4) == 0)
 ) {
   break;
 }
   }
+  if (LocalOptionType == ARRAY_SIZE (mBmLoadOptionName)) {
+return FALSE;
+  }
 
-  if (Index == ARRAY_SIZE (mBmLoadOptionName)) {
+  //
+  // Return FALSE when the last four characters are not hex digits.
+  //
+  LocalOptionNumber = 0;
+  for (Index = VariableNameLen - 4; Index < VariableNameLen; Index++) {
+Uint = BmCharToUint (VariableName[Index]);
+if (Uint == -1) {
+  break;
+} else {
+  LocalOptionNumber = (UINT16) Uint + LocalOptionNumber * 0x10;
+}
+  }
+  if (Index != VariableNameLen) {
 return FALSE;
   }
 
   if (OptionType != NULL) {
-*OptionType = (EFI_BOOT_MANAGER_LOAD_OPTION_TYPE) Index;
+*OptionType = LocalOptionType;
   }
 
   if (OptionNumber != NULL) {
-*OptionNumber = 0;
-for (Index = VariableNameLen - 4; Index < VariableNameLen; Index++) {
-  Uint = BmCharToUint (VariableName[Index]);
-  if (Uint == -1) {
-break;
-  } else {
-*OptionNumber = (UINT16) Uint + *OptionNumber * 0x10;
-  }
-}
+*OptionNumber = LocalOptionNumber;
   }
 
-  return (BOOLEAN) (Index == VariableNameLen);
+  return TRUE;
 }
 
 /**
-- 
2.12.2.windows.2

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

Re: [edk2] [PATCH] MdeModulePkg/Bds: Remove assertion in BmCharToUint

[Ard Biesheuvel]

On 10 October 2017 at 09:39, Ruiyu Ni  wrote:
> BmCharToUint() could be called using external data and it
> already contains logic to return -1 when data is invalid,
> so removing unnecessary assertion to avoid system hang.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Ard Biesheuvel 
> Cc: Laszlo Ersek 

Acked-by: Ard Biesheuvel 

> ---
>  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> index 11ab86792a..a3fa254245 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> @@ -420,7 +420,6 @@ BmCharToUint (
>  return (Char - L'A' + 0xA);
>}
>
> -  ASSERT (FALSE);
>return (UINTN) -1;
>  }
>
> --
> 2.12.2.windows.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 v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM installing

[Wang, Jian J]

Got it. Thank you very much for the advice and information.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, October 10, 2017 4:13 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Wolman, Ayellet
> ; Yao, Jiewen ; Dong, Eric
> ; Zeng, Star 
> Subject: Re: [edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL
> pointer detection during VBE SHIM installing
> 
> On 10/10/17 03:50, Wang, Jian J wrote:
> > I have summary in each patch email.
> 
> Sure, you have a commit message, but you didn't point out any v3->v4
> changes. (If there are no v3->v4 changes, then please pick up the R-b's
> received for v3.)
> 
> > I removed the CC of some patches because
> > there's no update from v3 to v4. I thought this could remind you of this
> situation.
> > What's the recommended way? Keep the CC as-was and just add summaries in
> > cover letter?
> 
> Maintainers should always be CC'd, even if there are no changes relative
> to the previous version.
> 
> Personally I prefer summarizing the changes in the cover letter, and
> also explaining the changes in more detail -- or pointing out the lack
> of any changes -- on each individual patch.
> 
> If you have a bit of time for reading, I recommend the following wiki
> article:
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-
> guide-for-edk2-contributors-and-maintainers
> 
> In it, I had written down most everything that I have in mind about the
> edk2 development process. The following steps pertain to the current
> discussion (i.e., picking up feedback tags, adding Maintainer CC's, and
> pointing out changes per patch):
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-
> guide-for-edk2-contributors-and-maintainers#contrib-18
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-
> guide-for-edk2-contributors-and-maintainers#contrib-28
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-
> guide-for-edk2-contributors-and-maintainers#contrib-30
> 
> Thanks,
> Laszlo
> 
> 
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Monday, October 09, 2017 11:56 PM
> >> To: Wang, Jian J ; edk2-devel@lists.01.org
> >> Cc: Kinney, Michael D ; Wolman, Ayellet
> >> ; Yao, Jiewen ; Dong,
> Eric
> >> ; Zeng, Star 
> >> Subject: Re: [edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL
> >> pointer detection during VBE SHIM installing
> >>
> >> On 10/09/17 17:54, Laszlo Ersek wrote:
> >>> On 10/09/17 16:17, Jian J Wang wrote:
>  QemuVideoDxe driver will link VBE SHIM into page 0. If NULL pointer
>  detection is enabled, this driver will fail to load. NULL pointer 
>  detection
>  bypassing code is added to prevent such problem during boot.
> 
>  Please note that Windows 7 will try to access VBE SHIM during boot if 
>  it's
>  installed, and then cause boot failure. This can be fixed by setting BIT7
>  of PcdNullPointerDetectionPropertyMask to disable NULL pointer
> detection
>  after EndOfDxe. As far as we know, there's no other OSs has such issue.
> 
>  Cc: Star Zeng 
>  Cc: Eric Dong 
>  Cc: Jiewen Yao 
>  Cc: Michael Kinney 
>  Cc: Ayellet Wolman 
>  Suggested-by: Ayellet Wolman 
>  Contributed-under: TianoCore Contribution Agreement 1.1
>  Signed-off-by: Jian J Wang 
>  ---
>   OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  1 +
>   OvmfPkg/QemuVideoDxe/VbeShim.c| 14 ++
>   2 files changed, 15 insertions(+)
> 
>  diff --git a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> >> b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>  index 577e07b0a8..ff68c99e96 100644
>  --- a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>  +++ b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>  @@ -77,3 +77,4 @@
>   [Pcd]
> gOptionRomPkgTokenSpaceGuid.PcdDriverSupportedEfiVersion
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
>  +
> >> gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
>  diff --git a/OvmfPkg/QemuVideoDxe/VbeShim.c
> >> b/OvmfPkg/QemuVideoDxe/VbeShim.c
>  index e45a08e887..8ba5522cde 100644
>  --- a/OvmfPkg/QemuVideoDxe/VbeShim.c
>  +++ b/OvmfPkg/QemuVideoDxe/VbeShim.c
>  @@ -75,6 +75,20 @@ InstallVbeShim (
> UINTNPrinted;
> VBE_MODE_INFO*VbeModeInfo;
> 
>  +  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) 

Re: [edk2] [Patch 08/11] SecurityPkg: Update Guid usage in INF file to match source code logic

[Zhang, Chao B]

Reviewed-by: Chao Zhang 

-Original Message-
From: Gao, Liming 
Sent: Monday, September 25, 2017 7:06 PM
To: edk2-devel@lists.01.org
Cc: Zhang, Chao B 
Subject: [Patch 08/11] SecurityPkg: Update Guid usage in INF file to match 
source code logic

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao 
Cc: Chao Zhang 
---
 .../FmpAuthenticationLibRsa2048Sha256.inf   | 6 +++---
 .../Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/SecurityPkg/Library/FmpAuthenticationLibRsa2048Sha256/FmpAuthenticationLibRsa2048Sha256.inf
 
b/SecurityPkg/Library/FmpAuthenticationLibRsa2048Sha256/FmpAuthenticationLibRsa2048Sha256.inf
index 633f407..b190eca 100644
--- 
a/SecurityPkg/Library/FmpAuthenticationLibRsa2048Sha256/FmpAuthenticationLibRsa2048Sha256.inf
+++ b/SecurityPkg/Library/FmpAuthenticationLibRsa2048Sha256/FmpAuthentic
+++ ationLibRsa2048Sha256.inf
@@ -3,7 +3,7 @@
 #
 # Instance of FmpAuthentication Library for DXE/PEI post memory phase.
 #
-#  Copyright (c) 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2016 - 2017, Intel Corporation. All rights 
+reserved.
 #  This program and the accompanying materials  #  are licensed and made 
available under the terms and conditions of the BSD License  #  which 
accompanies this distribution.  The full text of the license may be found at @@ 
-49,5 +49,5 @@
   gEfiSecurityPkgTokenSpaceGuid.PcdRsa2048Sha256PublicKeyBuffer ## CONSUMES
 
 [Guids]
-  gEfiCertTypeRsa2048Sha256Guid ## CONSUMES   ## GUID
-  gEfiHashAlgorithmSha256Guid   ## CONSUMES   ## GUID
+  gEfiCertTypeRsa2048Sha256Guid ## SOMETIMES_CONSUMES   ## GUID # 
Unique ID for the type of the certificate.
+  gEfiHashAlgorithmSha256Guid   ## SOMETIMES_CONSUMES   ## GUID
diff --git 
a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf 
b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf
index eebf90e..018090b 100644
--- a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf
+++ b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRoute
+++ rPei.inf
@@ -51,7 +51,7 @@
   HobLib
 
 [Guids]
-  ## CONSUMES   ## GUID
+  ## SOMETIMES_CONSUMES   ## GUID
   gZeroGuid
 
 [Pcd]
--
2.8.0.windows.1

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

[edk2] [PATCH] MdeModulePkg/Bds: Remove assertion in BmCharToUint

[Ruiyu Ni]

BmCharToUint() could be called using external data and it
already contains logic to return -1 when data is invalid,
so removing unnecessary assertion to avoid system hang.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Ard Biesheuvel 
Cc: Laszlo Ersek 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
index 11ab86792a..a3fa254245 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
@@ -420,7 +420,6 @@ BmCharToUint (
 return (Char - L'A' + 0xA);
   }
 
-  ASSERT (FALSE);
   return (UINTN) -1;
 }
 
-- 
2.12.2.windows.2

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

Re: [edk2] [PATCH] SecurityPkg/SecureBootConfigImpl.c: Fix the potential NULL dereference.

[Laszlo Ersek]

On 10/10/17 04:46, Wu, Hao A wrote:
> Some comments below.

Given that a new version of this patch looks necessary, I'd like to
request an improved subject line / commit message:


(1) For the subject prefix, we should use:

SecurityPkg/SecureBootConfigDxe: ...


(2) It looks like the issue (= NULL pointer dereferencing) can occur
when the platform does not install the appropriate strings into the HII
database. All these strings are apparently identified by STR_SIGNATURE_*
tokens. So how about the following subject:

  SecurityPkg/SecureBootConfigDxe: cope with lack of STR_SIGNATURE_* tokens

(This subject is 73 characters long.)


(3) Can we please capture some details about the issue in the commit
message? Namely, I thought it was not possible for these tokens to be
missing. Apparently they *can* be missing. Can we describe, briefly, how
and when that happens, in practice?

Thanks!
Laszlo


>> -Original Message-
>> From: Chen, Chen A
>> Sent: Tuesday, October 10, 2017 10:08 AM
>> To: edk2-devel@lists.01.org
>> Cc: Chen, Chen A; Zhang, Chao B; Wu, Hao A
>> Subject: [PATCH] SecurityPkg/SecureBootConfigImpl.c: Fix the potential NULL
>> dereference.
>>
>> Cc: Zhang Chao 
>> Cc: Wu Hao 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Chen A Chen 
>> ---
>>  .../SecureBootConfigDxe/SecureBootConfigImpl.c | 80 +++
>> ---
>>  1 file changed, 57 insertions(+), 23 deletions(-)
>>
>> diff --git
>> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigI
>> mpl.c
>> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigI
>> mpl.c
>> index 3e03be9738..457e020ece 100644
>> ---
>> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigI
>> mpl.c
>> +++
>> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigI
>> mpl.c
>> @@ -3579,7 +3579,9 @@ LoadSignatureList (
>>)
>>  {
>>EFI_STATUSStatus;
>> -  EFI_STRING_ID ListType;
>> +  EFI_STRINGEfiStringTemp1;
>> +  EFI_STRINGEfiStringTemp2;
>> +  EFI_STRING_ID ListType;;
>
> An extra ';' is used here.
>
>>EFI_SIGNATURE_LIST*ListWalker;
>>EFI_IFR_GUID_LABEL*StartLabel;
>>EFI_IFR_GUID_LABEL*EndLabel;
>> @@ -3599,6 +3601,8 @@ LoadSignatureList (
>>CHAR16*HelpBuffer;
>>
>>Status= EFI_SUCCESS;
>> +  EfiStringTemp1= NULL;
>> +  EfiStringTemp2= NULL;
>>StartOpCodeHandle = NULL;
>>EndOpCodeHandle   = NULL;
>>StartGotoHandle   = NULL;
>> @@ -3755,17 +3759,19 @@ LoadSignatureList (
>>ListType = STRING_TOKEN (STR_LIST_TYPE_UNKNOWN);
>>  }
>>
>> -UnicodeSPrint (NameBuffer,
>> -  100,
>> -  HiiGetString (PrivateData->HiiHandle, STRING_TOKEN
>> (STR_SIGNATURE_LIST_NAME_FORMAT), NULL),
>> -  Index + 1
>> -);
>> -UnicodeSPrint (HelpBuffer,
>> -  100,
>> -  HiiGetString (PrivateData->HiiHandle, STRING_TOKEN
>> (STR_SIGNATURE_LIST_HELP_FORMAT), NULL),
>> -  HiiGetString (PrivateData->HiiHandle, ListType, NULL),
>> -  SIGNATURE_DATA_COUNTS (ListWalker)
>> -);
>> +EfiStringTemp1 = HiiGetString (PrivateData->HiiHandle, STRING_TOKEN
>> (STR_SIGNATURE_LIST_NAME_FORMAT), NULL);
>> +if (EfiStringTemp1 == NULL) {
>> +  goto ON_EXIT;
>> +}
>> +UnicodeSPrint (NameBuffer, 100, EfiStringTemp1, Index + 1);
>> +EfiStringTemp1 = NULL;
>
> Before setting 'EfiStringTemp1' to NULL, I think the returned string from
> HiiGetString() should be freed first. There are many similar cases in the
> codes.
>
> Also, could you help to replace the usages of '100' like:
>
> *  VariableName = AllocateZeroPool (100);
> *  NameBuffer = AllocateZeroPool (100);
> *  UnicodeSPrint (NameBuffer, 100, EfiStringTemp1, Index + 1);
> ...
>
> with a macro? It will be helpful for maintaining the codes.
>
> And how about declaring string buffers like 'VariableName', 'NameBuffer'
> as arrays instead of allocating them on the heap?
>
>> +
>> +EfiStringTemp1 = HiiGetString (PrivateData->HiiHandle, STRING_TOKEN
>> (STR_SIGNATURE_LIST_HELP_FORMAT), NULL);
>> +EfiStringTemp2 = HiiGetString (PrivateData->HiiHandle, ListType, NULL);
>> +if (EfiStringTemp1 == NULL || EfiStringTemp2 == NULL) {
>> +  goto ON_EXIT;
>> +}
>> +UnicodeSPrint (HelpBuffer, 100, EfiStringTemp1, EfiStringTemp2,
>> SIGNATURE_DATA_COUNTS (ListWalker));
>>
>>  HiiCreateGotoOpCode (
>>StartOpCodeHandle,
>> @@ -3953,6 +3959,8 @@ FormatHelpInfo (
>>  {
>>EFI_STATUS  Status;
>>EFI_TIME*Time;
>> +  EFI_STRING  EfiStringTemp1;
>> +  EFI_STRING  EfiStringTemp2;
>>EFI_STRING_ID   ListTypeId;
>>UINTN   DataSize;
>>UINTN   HelpInfoIndex;
>> @@ -3964,6 +3972,8 @@ FormatHelpInfo (
>>BOOLEAN IsCert;
>>
>>Status  = EFI_SUCCESS;
>> +  

Re: [edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM installing

[Laszlo Ersek]

On 10/10/17 03:50, Wang, Jian J wrote:
> I have summary in each patch email.

Sure, you have a commit message, but you didn't point out any v3->v4
changes. (If there are no v3->v4 changes, then please pick up the R-b's
received for v3.)

> I removed the CC of some patches because 
> there's no update from v3 to v4. I thought this could remind you of this 
> situation.
> What's the recommended way? Keep the CC as-was and just add summaries in 
> cover letter?

Maintainers should always be CC'd, even if there are no changes relative
to the previous version.

Personally I prefer summarizing the changes in the cover letter, and
also explaining the changes in more detail -- or pointing out the lack
of any changes -- on each individual patch.

If you have a bit of time for reading, I recommend the following wiki
article:

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers

In it, I had written down most everything that I have in mind about the
edk2 development process. The following steps pertain to the current
discussion (i.e., picking up feedback tags, adding Maintainer CC's, and
pointing out changes per patch):

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-18

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-28

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-30

Thanks,
Laszlo


> 
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Monday, October 09, 2017 11:56 PM
>> To: Wang, Jian J ; edk2-devel@lists.01.org
>> Cc: Kinney, Michael D ; Wolman, Ayellet
>> ; Yao, Jiewen ; Dong, Eric
>> ; Zeng, Star 
>> Subject: Re: [edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL
>> pointer detection during VBE SHIM installing
>>
>> On 10/09/17 17:54, Laszlo Ersek wrote:
>>> On 10/09/17 16:17, Jian J Wang wrote:
 QemuVideoDxe driver will link VBE SHIM into page 0. If NULL pointer
 detection is enabled, this driver will fail to load. NULL pointer detection
 bypassing code is added to prevent such problem during boot.

 Please note that Windows 7 will try to access VBE SHIM during boot if it's
 installed, and then cause boot failure. This can be fixed by setting BIT7
 of PcdNullPointerDetectionPropertyMask to disable NULL pointer detection
 after EndOfDxe. As far as we know, there's no other OSs has such issue.

 Cc: Star Zeng 
 Cc: Eric Dong 
 Cc: Jiewen Yao 
 Cc: Michael Kinney 
 Cc: Ayellet Wolman 
 Suggested-by: Ayellet Wolman 
 Contributed-under: TianoCore Contribution Agreement 1.1
 Signed-off-by: Jian J Wang 
 ---
  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  1 +
  OvmfPkg/QemuVideoDxe/VbeShim.c| 14 ++
  2 files changed, 15 insertions(+)

 diff --git a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>> b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
 index 577e07b0a8..ff68c99e96 100644
 --- a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
 +++ b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
 @@ -77,3 +77,4 @@
  [Pcd]
gOptionRomPkgTokenSpaceGuid.PcdDriverSupportedEfiVersion
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
 +
>> gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
 diff --git a/OvmfPkg/QemuVideoDxe/VbeShim.c
>> b/OvmfPkg/QemuVideoDxe/VbeShim.c
 index e45a08e887..8ba5522cde 100644
 --- a/OvmfPkg/QemuVideoDxe/VbeShim.c
 +++ b/OvmfPkg/QemuVideoDxe/VbeShim.c
 @@ -75,6 +75,20 @@ InstallVbeShim (
UINTNPrinted;
VBE_MODE_INFO*VbeModeInfo;

 +  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT0|BIT7)) == 
 BIT0)
>> {
 +DEBUG ((
 +  DEBUG_WARN,
 +  "%a: page 0 protected, not installing VBE shim\n",
 +  __FUNCTION__
 +  ));
 +DEBUG ((
 +  DEBUG_WARN,
 +  "%a: page 0 protection prevents Windows 7 from booting anyway\n",
 +  __FUNCTION__
 +  ));
 +return;
 +  }
 +
Segment0 = 0x0;
SegmentC = 0xC;
SegmentF = 0xF;

>>>
>>> If this patch is entirely identical to the previous version (v3), then
>>> you should have please picked up the review tags from Jordan and myself,
>>> the ones that you got for v3:
>>>
>>> http://mid.mail-
>> archive.com/150696711831.2454.16712170525103415248@jljusten-skl
>>>
>>> 

Re: [edk2] [Patch 06/11] NetworkPkg: Update Protocol/Guid usage in INF file to match source code logic

[Wu, Jiaxin]

Reviewed-by: Wu Jiaxin 


> -Original Message-
> From: Gao, Liming
> Sent: Monday, September 25, 2017 7:06 PM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Wu, Jiaxin 
> Subject: [Patch 06/11] NetworkPkg: Update Protocol/Guid usage in INF file to
> match source code logic
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> Cc: Siyuan Fu 
> Cc: Jiaxin Wu 
> ---
>  NetworkPkg/HttpDxe/HttpDxe.inf   | 2 +-
>  NetworkPkg/IScsiDxe/IScsiDxe.inf | 2 +-
>  NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf | 8 
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf
> b/NetworkPkg/HttpDxe/HttpDxe.inf
> index df2efdc..51deec5 100644
> --- a/NetworkPkg/HttpDxe/HttpDxe.inf
> +++ b/NetworkPkg/HttpDxe/HttpDxe.inf
> @@ -73,7 +73,7 @@
>gEfiTlsConfigurationProtocolGuid ## SOMETIMES_CONSUMES
> 
>  [Guids]
> -  gEfiTlsCaCertificateGuid ## CONSUMES  ## GUID
> +  gEfiTlsCaCertificateGuid ## SOMETIMES_CONSUMES  ##
> Variable:L"TlsCaCertificate"
> 
>  [Pcd]
>gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections   ##
> CONSUMES
> diff --git a/NetworkPkg/IScsiDxe/IScsiDxe.inf
> b/NetworkPkg/IScsiDxe/IScsiDxe.inf
> index c9b724b..01998a0 100644
> --- a/NetworkPkg/IScsiDxe/IScsiDxe.inf
> +++ b/NetworkPkg/IScsiDxe/IScsiDxe.inf
> @@ -115,7 +115,7 @@
>gEfiIScsiInitiatorNameProtocolGuid
>## PRODUCES
>gEfiAuthenticationInfoProtocolGuid
> -  ## CONSUMES
> +  ## SOMETIMES_CONSUMES
>gEfiAdapterInformationProtocolGuid
> 
>  [Guids]
> diff --git a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
> b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
> index 2a89368..3cfcdb9 100644
> --- a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
> +++ b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
> @@ -2,7 +2,7 @@
>  #  Provides the capability to configure Tls Authentication in a setup browser
>  #  By this module, user may change the content of TlsCaCertificate.
>  #
> -# Copyright (c) 2016, Intel Corporation. All rights reserved.
> +# Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
>  # This program and the accompanying materials
>  # are licensed and made available under the terms and conditions of the BSD
> License
>  # which accompanies this distribution. The full text of the license may be
> found at
> @@ -61,9 +61,9 @@
> 
>  [Guids]
>gTlsAuthConfigGuid## PRODUCES  ## GUID
> -  gEfiCertX509Guid  ## CONSUMES  ## GUID  # 
> Indicate the
> cert type
> -  gEfiIfrTianoGuid  ## CONSUMES  ## HII
> -  gEfiTlsCaCertificateGuid  ## PRODUCES  ## GUID
> +  gEfiCertX509Guid  ## SOMETIMES_CONSUMES  ## 
> GUID  #
> Indicate the cert type
> +  gEfiIfrTianoGuid  ## SOMETIMES_PRODUCES  ## HII
> +  gEfiTlsCaCertificateGuid  ## PRODUCES  ##
> Variable:L"TlsCaCertificate"
> 
>  [Depex]
>gEfiHiiConfigRoutingProtocolGuid  AND
> --
> 2.8.0.windows.1

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

Re: [edk2] Request to display Initiator IP in ISCSI Attempt Page

[Wu, Jiaxin]

Hi Karunakar,

Unlike IPv4, IPv6 address used for iSCSI session can always be retrieved 
manually. Since we expect the user configure the IPv6 address manually, I don't 
prefer adding the Initiator IP In IP6 attempt Page because the user should have 
known it as setting in step1.

Thanks,
Jiaxin


From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Tuesday, October 10, 2017 12:09 PM
To: Wu, Jiaxin ; 'edk2-devel@lists.01.org' 

Cc: Fu, Siyuan ; Ye, Ting 
Subject: RE: Request to display Initiator IP in ISCSI Attempt Page

Hi Jiaxin,

Thanks for your support.

I've created a ticket in Bugzilla, and below are the details
https://bugzilla.tianocore.org/show_bug.cgi?id=732

Yeah we should  grayout the Initiator info to indicate it's un-configurable.

In case of IPv6

1.   Before trying for ISCSI connection(with IPv6 attempt), we'll configure 
the IP manually.

2.   While trying for ISCSI Connection(with IPv6 attempt), It may use the 
above Configured IP or link local address.

3.   Can we display the whatever IP used for ISCSI connection(with IPv6 
attempt) as Initiator IP In IP6 attempt Page? , So that we can know what 
Initiator IP used for ISCSI connection.


Could you please let me know if anything is wrong.

Thanks,
Karunakar

From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Tuesday, October 10, 2017 8:07 AM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Fu, Siyuan; Ye, Ting
Subject: RE: Request to display Initiator IP in ISCSI Attempt Page

Hi Karunakar,

We agree to add this feature for the Initiator info of IPv4 when DHCP enabled. 
Can you report it on Bugzilla first?

To achieve that,  we can grayout the Initiator IP/Subnet/Gateway if Initiator 
DHCP enabled to indicate it's un-configurable. For IPv6, since iSCSI only 
request the target info from DHCP server, so, it's unnecessary to display the 
info as IPv4.

Thanks,
Jiaxin


From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Friday, October 6, 2017 5:28 PM
To: 'edk2-devel@lists.01.org' 
>
Cc: Fu, Siyuan >; Wu, Jiaxin 
>; Ye, Ting 
>
Subject: RE: Request to display Initiator IP in ISCSI Attempt Page

Hello All,

We have a requirement to display Initiator IP in ISCSI Configuration Page when 
Initiator info is enabled for DHCP, find detailed description below.


1.   Add an Attempt with Initiator info Enabled for DHCP

2.   Save changes

3.   On next reboot, Previously added ISCSI attempt will be tried and ISCSI 
DHCP server will assign an IP to the client (Initiator IP).

4.   It is better to display Initiator IP in same attempt Page like below



Ex:- Initiator IP : 192.168.0.5 // DHCP Process was success

 Initiator IP : 0.0.0.0 // DHCP process failed

Could you please provide your comments to support this feature?

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

Re: [edk2] [Patch 09/11] IntelFsp2Pkg: Update Section Name in INF files

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Gao, Liming
> Sent: Monday, September 25, 2017 7:06 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: [Patch 09/11] IntelFsp2Pkg: Update Section Name in INF files
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> Cc: Jiewen Yao 
> ---
>  IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.inf  | 3
> +--
>  .../Library/BaseCacheAsRamLibNull/BaseCacheAsRamLibNull.inf | 6
> +++---
>  IntelFsp2Pkg/Library/BaseCacheLib/BaseCacheLib.inf  | 6
> +++---
>  3 files changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.inf
> b/IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.inf
> index 75f7ae5..a0bc375 100644
> --- a/IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.inf
> +++ b/IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.inf
> @@ -1,8 +1,7 @@
>  ## @file
>  # Component information file for the FSP notify phase PEI module.
>  #
> -#@copyright
> -#  Copyright (c) 2016 Intel Corporation. All rights reserved.
> +#  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD
> License
>  #  which accompanies this distribution.  The full text of the license may be
> found at
> diff --git
> a/IntelFsp2Pkg/Library/BaseCacheAsRamLibNull/BaseCacheAsRamLibNull.inf
> b/IntelFsp2Pkg/Library/BaseCacheAsRamLibNull/BaseCacheAsRamLibNull.inf
> index bdb6744..6a77ce7 100644
> --- a/IntelFsp2Pkg/Library/BaseCacheAsRamLibNull/BaseCacheAsRamLibNull.inf
> +++
> b/IntelFsp2Pkg/Library/BaseCacheAsRamLibNull/BaseCacheAsRamLibNull.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  NULL instance of Base cache as RAM.
>  #
> -#  Copyright (c) 2014 - 2015, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2014 - 2017, 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
> @@ -12,7 +12,7 @@
>  #
>  ##
> 
> -[defines]
> +[Defines]
>INF_VERSION= 0x00010005
>BASE_NAME  = BaseCacheAsRamLibNull
>FILE_GUID  =
> 630AEB10-2106-4234-9DB3-836A3663F50D
> @@ -20,7 +20,7 @@
>VERSION_STRING = 1.0
>LIBRARY_CLASS  = CacheAsRamLib
> 
> -[sources.common]
> +[Sources.common]
>DisableCacheAsRamNull.c
> 
>  [Packages]
> diff --git a/IntelFsp2Pkg/Library/BaseCacheLib/BaseCacheLib.inf
> b/IntelFsp2Pkg/Library/BaseCacheLib/BaseCacheLib.inf
> index 7b026b1..34df6ad 100644
> --- a/IntelFsp2Pkg/Library/BaseCacheLib/BaseCacheLib.inf
> +++ b/IntelFsp2Pkg/Library/BaseCacheLib/BaseCacheLib.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  Instance of BaseCache.
>  #
> -#  Copyright (c) 2014 - 2015, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2014 - 2017, 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
> @@ -12,7 +12,7 @@
>  #
>  ##
> 
> -[defines]
> +[Defines]
>INF_VERSION= 0x00010005
>BASE_NAME  = BaseCacheLib
>FILE_GUID  =
> 8EF3A653-DA8B-4FFA-BB85-FF47406DB9F0
> @@ -20,7 +20,7 @@
>VERSION_STRING = 1.0
>LIBRARY_CLASS  = CacheLib
> 
> -[sources.IA32]
> +[Sources.IA32]
>CacheLib.c
>CacheLibInternal.h
> 
> --
> 2.8.0.windows.1

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

Re: [edk2] [Patch 10/11] IntelFsp2WrapperPkg: Update Protocol/Guid usage in INF files

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Gao, Liming
> Sent: Monday, September 25, 2017 7:06 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: [Patch 10/11] IntelFsp2WrapperPkg: Update Protocol/Guid usage in INF
> files
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> Cc: Jiewen Yao 
> ---
>  IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.inf  | 6
> +++---
>  IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf  | 9
> ++---
>  IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf  | 6
> +++---
>  .../Library/PeiFspWrapperApiTestLib/PeiFspWrapperApiTestLib.inf  | 4 ++--
>  4 files changed, 10 insertions(+), 15 deletions(-)
> 
> diff --git
> a/IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.inf
> b/IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.inf
> index 54c2cbf..ce3bfa0 100644
> --- a/IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.inf
> +++ b/IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.inf
> @@ -3,7 +3,7 @@
>  #
>  # This driver will register two callbacks to call fsp's notifies.
>  #
> -#  Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2014 - 2017, 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
> @@ -53,10 +53,10 @@
> 
>  [Protocols]
>gEfiPciEnumerationCompleteProtocolGuid## CONSUMES
> -  gAddPerfRecordProtocolGuid## CONSUMES
> +  gAddPerfRecordProtocolGuid##
> SOMETIMES_CONSUMES
> 
>  [Guids]
> -  gFspApiPerformanceGuid## CONSUMES ##
> GUID
> +  gFspApiPerformanceGuid##
> SOMETIMES_CONSUMES ## GUID
>gEfiEventExitBootServicesGuid ## CONSUMES ##
> Event
>gFspHobGuid   ## CONSUMES ##
> HOB
> 
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> index 0901a14..2b3d240 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> @@ -6,7 +6,7 @@
>  # register TemporaryRamDonePpi to call TempRamExit API, and register
> MemoryDiscoveredPpi
>  # notify to call FspSiliconInit API.
>  #
> -#  Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2014 - 2017, 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
> @@ -64,14 +64,9 @@
>  [Sources]
>FspmWrapperPeim.c
> 
> -[Ppis]
> -  gTopOfTemporaryRamPpiGuid ## PRODUCES
> -  gEfiEndOfPeiSignalPpiGuid ## PRODUCES
> -  gEfiPeiMemoryDiscoveredPpiGuid## PRODUCES
> -
>  [Guids]
>gFspHobGuid   ## PRODUCES ## HOB
> -  gFspApiPerformanceGuid## CONSUMES ## GUID
> +  gFspApiPerformanceGuid## SOMETIMES_CONSUMES ##
> GUID
> 
>  [Depex]
>gEfiPeiMasterBootModePpiGuid
> diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
> b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
> index 261278f..c858e70 100644
> --- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
> +++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
> @@ -6,7 +6,7 @@
>  # register TemporaryRamDonePpi to call TempRamExit API, and register
> MemoryDiscoveredPpi
>  # notify to call FspSiliconInit API.
>  #
> -#  Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2014 - 2017, 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
> @@ -63,14 +63,14 @@
>gFspSiliconInitDonePpiGuid## PRODUCES
>gEfiEndOfPeiSignalPpiGuid ## PRODUCES
>gEfiTemporaryRamDonePpiGuid   ## PRODUCES
> -  gEfiPeiMemoryDiscoveredPpiGuid## PRODUCES
> +  gEfiPeiMemoryDiscoveredPpiGuid## NOTIFY
> 
>  [Pcd]
>gIntelFsp2WrapperTokenSpaceGuid.PcdFspsBaseAddress  ## CONSUMES
> 
>  [Guids]
>gFspHobGuid   ## CONSUMES ## HOB
> -  gFspApiPerformanceGuid## CONSUMES ## GUID
> +  gFspApiPerformanceGuid## SOMETIMES_CONSUMES ##
> GUID
> 
>  [Sources]
>FspsWrapperPeim.c
> diff --git
> a/IntelFsp2WrapperPkg/Library/PeiFspWrapperApiTestLib/PeiFspWrapperApiTes
> tLib.inf
> b/IntelFsp2WrapperPkg/Library/PeiFspWrapperApiTestLib/PeiFspWrapperApiTe
> stLib.inf
> index fbbcf30..1a5029b 100644
> ---
> 

Re: [edk2] [Patch 07/11] SignedCapsulePkg: Update Guid usage in INF file to match source code logic

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Gao, Liming
> Sent: Monday, September 25, 2017 7:06 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: [Patch 07/11] SignedCapsulePkg: Update Guid usage in INF file to 
> match
> source code logic
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> Cc: Jiewen Yao 
> ---
>  .../Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.inf  | 12 
> ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git
> a/SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.inf
> b/SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.inf
> index a7c9607..a21e75c 100644
> ---
> a/SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.inf
> +++
> b/SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.inf
> @@ -3,7 +3,7 @@
>  #
>  #  EDKII System Capsule library instance for DXE/PEI post memory phase.
>  #
> -#  Copyright (c) 2016, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD
> License
>  #  which accompanies this distribution.  The full text of the license may be
> found at
> @@ -53,9 +53,9 @@
>gEfiSecurityPkgTokenSpaceGuid.PcdPkcs7CertBuffer
> ## CONSUMES
> 
>  [Guids]
> -  gEdkiiSystemFirmwareImageDescriptorFileGuid  ## CONSUMES
> ## GUID
> -  gEdkiiSystemFmpCapsuleConfigFileGuid ## CONSUMES
> ## GUID
> -  gEdkiiSystemFmpCapsuleDriverFvFileGuid   ## CONSUMES
> ## GUID
> -  gEfiCertPkcs7Guid## CONSUMES
> ## GUID
> -  gEfiCertTypeRsa2048Sha256Guid## CONSUMES
> ## GUID
> +  gEdkiiSystemFirmwareImageDescriptorFileGuid  ##
> SOMETIMES_CONSUMES   ## GUID
> +  gEdkiiSystemFmpCapsuleConfigFileGuid ##
> SOMETIMES_CONSUMES   ## GUID
> +  gEdkiiSystemFmpCapsuleDriverFvFileGuid   ##
> SOMETIMES_CONSUMES   ## GUID
> +  gEfiCertPkcs7Guid##
> SOMETIMES_CONSUMES   ## GUID
> +  gEfiCertTypeRsa2048Sha256Guid##
> SOMETIMES_CONSUMES   ## GUID
> 
> --
> 2.8.0.windows.1

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