Re: [edk2-devel] [PATCH] NetworkPkg: Correct the length of EAP Identity when in ASCII format

2023-06-22 Thread Clark-williams, Zachary 
Hey Yi,

I agree with the flow you have in the PR link and removing the extra protocol 
locate.

My only comment is to align your comments with the commenting style of the file.
Instead of /**/, use // for both single and multi-line comments.
Example included in the comments on the PR.

Thanks,
Zack


From: devel@edk2.groups.io  On Behalf Of Li, Yi
Sent: Monday, June 19, 2023 9:49 PM
To: Clark-williams; Clark-williams, Zachary ; 
devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH] NetworkPkg: Correct the length of EAP 
Identity when in ASCII format

Hi Zachary,

Thanks for review.
The protocol has changes since ADL from PlatSapmle to an advanced feature and 
the Protocol has shifted into EDK2, so the protocol name needs to be updated:
+  Status = gBS->LocateProtocol (, NULL, (VOID **) 
);
Status = gBS->LocateProtocol (, NULL, 
(VOID **));

The locate protocol status check is enough and we do not need to add the NULL 
check too, we can remove that to keep it lighter.
+if (!EFI_ERROR (Status) && WiFiProfileSyncProtocol != NULL) {
Agree with those changes, please check latest V2 patch or this PR: 
https://github.com/tianocore/edk2/pull/4561
Can we clean up the second locate protocol and bring the Identity allocate 
above the protocol check, and bring the two conditions for EapIdentity copied 
to Identity into the added protocol check condition.
Here is a view of what I am thinking for consolidation.
We need to get the Identity size before AllocateZeroPool(), not feasible here 
IMO.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106291): https://edk2.groups.io/g/devel/message/106291
Mute This Topic: https://groups.io/mt/99335243/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 7/7] OvmfPkg/RiscVVirt: SEC: Add IO memory resource hob for platform devices

2023-06-22 Thread Tuan Phan 
On Thu, Jun 22, 2023 at 11:41 AM Tuan Phan  wrote:

>
>
> On Tue, May 30, 2023 at 10:38 AM Tuan Phan via groups.io  ventanamicro@groups.io> wrote:
>
>>
>>
>> On Mon, May 29, 2023 at 7:07 AM Ard Biesheuvel  wrote:
>>
>>> On Sat, 27 May 2023 at 01:18, Tuan Phan  wrote:
>>> >
>>> > Normally, DXE driver would add device resource to GCD before start
>>> using.
>>> > But some key resources such as uart, flash base address are being
>>> accessing
>>> > directly in some core modules.
>>> >
>>> > Those resources should be populated to HOB in SEC phase so they are
>>> > added to GCD before anyone can access them.
>>> >
>>>
>>> Why should these be in the GCD to begin with?
>>>
>>
>> These resources should be in memory space so their addresses and size are
>> registered with MMU. If not when MMU enabled, illegal access exception when
>> someone access them.
>>
>> Hi Ard,
> Do you still have concerns about this patch?
>
BTW, I will drop this patch and put VirtNorFlashDxe in APRIORI DXE list to
make sure it runs before VariableRuntimeDxe.

>
>>> > Signed-off-by: Tuan Phan 
>>> > Reviewed-by: Andrei Warkentin 
>>>
>>> > ---
>>> >  OvmfPkg/RiscVVirt/Sec/Platform.c  | 62 +++
>>> >  OvmfPkg/RiscVVirt/Sec/SecMain.inf |  1 +
>>> >  2 files changed, 63 insertions(+)
>>> >
>>> > diff --git a/OvmfPkg/RiscVVirt/Sec/Platform.c
>>> b/OvmfPkg/RiscVVirt/Sec/Platform.c
>>> > index 3645c27b0b12..944b82c84a6e 100644
>>> > --- a/OvmfPkg/RiscVVirt/Sec/Platform.c
>>> > +++ b/OvmfPkg/RiscVVirt/Sec/Platform.c
>>> > @@ -21,6 +21,63 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>>> >  #include 
>>> >  #include 
>>> >
>>> > +/**
>>> > +  Build memory map I/O range resource HOB using the
>>> > +  base address and size.
>>> > +
>>> > +  @param  MemoryBase Memory map I/O base.
>>> > +  @param  MemorySize Memory map I/O size.
>>> > +
>>> > +**/
>>> > +STATIC
>>> > +VOID
>>> > +AddIoMemoryBaseSizeHob (
>>> > +  EFI_PHYSICAL_ADDRESS  MemoryBase,
>>> > +  UINT64MemorySize
>>> > +  )
>>> > +{
>>> > +  /* Align to EFI_PAGE_SIZE */
>>> > +  MemorySize = ALIGN_VALUE (MemorySize, EFI_PAGE_SIZE);
>>> > +  BuildResourceDescriptorHob (
>>> > +EFI_RESOURCE_MEMORY_MAPPED_IO,
>>> > +EFI_RESOURCE_ATTRIBUTE_PRESENT |
>>> > +EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
>>> > +EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
>>> > +EFI_RESOURCE_ATTRIBUTE_TESTED,
>>> > +MemoryBase,
>>> > +MemorySize
>>> > +);
>>> > +}
>>> > +
>>> > +/**
>>> > +  Populate IO resources from FDT that not added to GCD by its
>>> > +  driver in the DXE phase.
>>> > +
>>> > +  @param  FdtBase   Fdt base address
>>> > +  @param  CompatibleCompatible string
>>> > +
>>> > +**/
>>> > +STATIC
>>> > +VOID
>>> > +PopulateIoResources (
>>> > +  VOID  *FdtBase,
>>> > +  CONST CHAR8*  Compatible
>>> > +  )
>>> > +{
>>> > +  UINT64  *Reg;
>>> > +  INT32   Node, LenP;
>>> > +
>>> > +  Node = fdt_node_offset_by_compatible (FdtBase, -1, Compatible);
>>> > +  while (Node != -FDT_ERR_NOTFOUND) {
>>> > +Reg = (UINT64 *)fdt_getprop (FdtBase, Node, "reg", );
>>> > +if (Reg) {
>>> > +  ASSERT (LenP == (2 * sizeof (UINT64)));
>>> > +  AddIoMemoryBaseSizeHob (SwapBytes64 (Reg[0]), SwapBytes64
>>> (Reg[1]));
>>> > +}
>>> > +Node = fdt_node_offset_by_compatible (FdtBase, Node, Compatible);
>>> > +  }
>>> > +}
>>> > +
>>> >  /**
>>> >@retval EFI_SUCCESSThe address of FDT is passed in HOB.
>>> >EFI_UNSUPPORTEDCan't locate FDT.
>>> > @@ -80,5 +137,10 @@ PlatformPeimInitialization (
>>> >
>>> >BuildFvHob (PcdGet32 (PcdOvmfDxeMemFvBase), PcdGet32
>>> (PcdOvmfDxeMemFvSize));
>>> >
>>> > +  PopulateIoResources (Base, "ns16550a");
>>> > +  PopulateIoResources (Base, "qemu,fw-cfg-mmio");
>>> > +  PopulateIoResources (Base, "virtio,mmio");
>>> > +  AddIoMemoryBaseSizeHob (PcdGet32 (PcdOvmfFdBaseAddress), PcdGet32
>>> (PcdOvmfFirmwareFdSize));
>>> > +
>>> >return EFI_SUCCESS;
>>> >  }
>>> > diff --git a/OvmfPkg/RiscVVirt/Sec/SecMain.inf
>>> b/OvmfPkg/RiscVVirt/Sec/SecMain.inf
>>> > index 0e2a5785e8a4..75d5b74b3d3f 100644
>>> > --- a/OvmfPkg/RiscVVirt/Sec/SecMain.inf
>>> > +++ b/OvmfPkg/RiscVVirt/Sec/SecMain.inf
>>> > @@ -62,6 +62,7 @@
>>> >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
>>> >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
>>> >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
>>> > +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize
>>> >
>>> >  [Guids]
>>> >gFdtHobGuid
>>> > --
>>> > 2.25.1
>>> >
>>> >
>>> >
>>> > 
>>> > Groups.io Links: You receive all messages sent to this group.
>>> > View/Reply Online (#105346):
>>> https://edk2.groups.io/g/devel/message/105346
>>> > Mute This Topic: https://groups.io/mt/9916/1131722
>>> > Group Owner: devel+ow...@edk2.groups.io
>>> > Unsubscribe: https://edk2.groups.io/g/devel/unsub [a...@kernel.org]
>>> > 
>>> >
>>> >
>>>
>> 
>>
>>


-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/2] ArmPkg: MmCommunicationPei: Introduce MM communicate in PEI

2023-06-22 Thread Sami Mujawar 

Hi Kun,

Thank you for this patch.

Please find my response inline marked [SAMI].

Regards,

Sami Mujawar

On 08/06/2023 09:44 pm, Kun Qin wrote:

From: Kun Qin

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

This change introduced the MM communicate support in PEI phase for ARM
based platforms. Similar to the DXE counterpart, `PcdMmBufferBase` is
used as communicate buffer and SMC will be invoked to communicate to
TrustZone when MMI is requested.

Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Sami Mujawar

Co-authored-by: Ronny Hansen
Co-authored-by: Shriram Masanamuthu Chinnathurai
Co-authored-by: Preshit Harlikar
Signed-off-by: Kun Qin
---
  ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.c   | 178 

  ArmPkg/ArmPkg.dsc|   2 +
  ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.h   |  76 +
  ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.inf |  41 +
  4 files changed, 297 insertions(+)

diff --git a/ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.c 
b/ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.c
new file mode 100644
index ..0f1f763a347d
--- /dev/null
+++ b/ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.c
@@ -0,0 +1,178 @@
+/** @file -- MmCommunicationPei.c

+  Provides an interface to send MM request in PEI

+

+  Copyright (c) 2016-2021, Arm Limited. All rights reserved.

+  Copyright (c) Microsoft Corporation.

+  SPDX-License-Identifier: BSD-2-Clause-Patent

+**/

+

+#include "MmCommunicationPei.h"

+

+//

+// Module globals

+//

+EFI_PEI_MM_COMMUNICATION_PPI  mPeiMmCommunication = {

+  MmCommunicationPeim

+};

+

+EFI_PEI_PPI_DESCRIPTOR  mPeiMmCommunicationPpi = {

+  (EFI_PEI_PPI_DESCRIPTOR_PPI | EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),

+  ,

+  

+};

+

+/**

+  Entry point of PEI MM Communication driver

+

+  @param  FileHandle   Handle of the file being invoked.

+   Type EFI_PEI_FILE_HANDLE is defined in 
FfsFindNextFile().

+  @param  PeiServices  General purpose services available to every PEIM.

+

+  @retval EFI_SUCCESS  If the interface could be successfully installed

+  @retval Others   Returned from PeiServicesInstallPpi()

+**/

+EFI_STATUS

+EFIAPI

+MmCommunicationPeiInitialize (

+  IN   EFI_PEI_FILE_HANDLE  FileHandle,

+  IN CONST EFI_PEI_SERVICES **PeiServices

+  )

+{

+  return PeiServicesInstallPpi ();

+}

+

+/**

+  MmCommunicationPeim

+  Communicates with a registered handler.

+  This function provides a service to send and receive messages from a 
registered UEFI service during PEI.

+

+  @param[in]  ThisThe EFI_PEI_MM_COMMUNICATION_PPI instance.

+  @param[in, out] CommBuffer  Pointer to the data buffer

+  @param[in, out] CommSizeThe size of the data buffer being passed in. 
On exit, the

+  size of data being returned. Zero if the 
handler does not

+  wish to reply with any data.

+

+  @retval EFI_SUCCESS The message was successfully posted.

+  @retval EFI_INVALID_PARAMETER   CommBuffer was NULL or *CommSize does not 
match

+  MessageLength + sizeof 
(EFI_MM_COMMUNICATE_HEADER).

+  @retval EFI_BAD_BUFFER_SIZE The buffer is too large for the MM 
implementation.

+  If this error is returned, the MessageLength 
field

+  in the CommBuffer header or the integer 
pointed by

+  CommSize, are updated to reflect the maximum 
payload

+  size the implementation can accommodate.

+  @retval EFI_ACCESS_DENIED   The CommunicateBuffer parameter or CommSize 
parameter,

+  if not omitted, are in address range that 
cannot be

+  accessed by the MM environment.

+**/

+EFI_STATUS

+EFIAPI

+MmCommunicationPeim (

+  IN CONST EFI_PEI_MM_COMMUNICATION_PPI  *This,

+  IN OUT VOID*CommBuffer,

+  IN OUT UINTN   *CommSize

+  )

+{

+  EFI_MM_COMMUNICATE_HEADER  *CommunicateHeader;

+  ARM_SMC_ARGS   CommunicateSmcArgs;

+  EFI_STATUS Status;

+  UINTN  BufferSize;

+

+  Status = EFI_ACCESS_DENIED;

+  BufferSize = 0;
[SAMI] Minor optimisation: The above initialisations are probably not 
required.


+

+  ZeroMem (, sizeof (ARM_SMC_ARGS));

+

+  // Check that our static buffer is looking good.

+  // We are using PcdMmBufferBase to transfer variable data.

+  // We are not using the full size of the buffer since there is a cost

+  // of copying data between Normal and Secure World.

+  ASSERT (PcdGet64 (PcdMmBufferSize) > 0 && PcdGet64 (PcdMmBufferBase) != 0);

+

+  //

+  // Check parameters

+  //

+  if (CommBuffer == NULL) {

+return EFI_INVALID_PARAMETER;

+  }
[SAMI]

Re: [edk2-devel] [PATCH v3 7/7] OvmfPkg/RiscVVirt: SEC: Add IO memory resource hob for platform devices

2023-06-22 Thread Tuan Phan 
On Tue, May 30, 2023 at 10:38 AM Tuan Phan via groups.io  wrote:

>
>
> On Mon, May 29, 2023 at 7:07 AM Ard Biesheuvel  wrote:
>
>> On Sat, 27 May 2023 at 01:18, Tuan Phan  wrote:
>> >
>> > Normally, DXE driver would add device resource to GCD before start
>> using.
>> > But some key resources such as uart, flash base address are being
>> accessing
>> > directly in some core modules.
>> >
>> > Those resources should be populated to HOB in SEC phase so they are
>> > added to GCD before anyone can access them.
>> >
>>
>> Why should these be in the GCD to begin with?
>>
>
> These resources should be in memory space so their addresses and size are
> registered with MMU. If not when MMU enabled, illegal access exception when
> someone access them.
>
> Hi Ard,
Do you still have concerns about this patch?

>
>> > Signed-off-by: Tuan Phan 
>> > Reviewed-by: Andrei Warkentin 
>>
>> > ---
>> >  OvmfPkg/RiscVVirt/Sec/Platform.c  | 62 +++
>> >  OvmfPkg/RiscVVirt/Sec/SecMain.inf |  1 +
>> >  2 files changed, 63 insertions(+)
>> >
>> > diff --git a/OvmfPkg/RiscVVirt/Sec/Platform.c
>> b/OvmfPkg/RiscVVirt/Sec/Platform.c
>> > index 3645c27b0b12..944b82c84a6e 100644
>> > --- a/OvmfPkg/RiscVVirt/Sec/Platform.c
>> > +++ b/OvmfPkg/RiscVVirt/Sec/Platform.c
>> > @@ -21,6 +21,63 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>> >  #include 
>> >  #include 
>> >
>> > +/**
>> > +  Build memory map I/O range resource HOB using the
>> > +  base address and size.
>> > +
>> > +  @param  MemoryBase Memory map I/O base.
>> > +  @param  MemorySize Memory map I/O size.
>> > +
>> > +**/
>> > +STATIC
>> > +VOID
>> > +AddIoMemoryBaseSizeHob (
>> > +  EFI_PHYSICAL_ADDRESS  MemoryBase,
>> > +  UINT64MemorySize
>> > +  )
>> > +{
>> > +  /* Align to EFI_PAGE_SIZE */
>> > +  MemorySize = ALIGN_VALUE (MemorySize, EFI_PAGE_SIZE);
>> > +  BuildResourceDescriptorHob (
>> > +EFI_RESOURCE_MEMORY_MAPPED_IO,
>> > +EFI_RESOURCE_ATTRIBUTE_PRESENT |
>> > +EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
>> > +EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
>> > +EFI_RESOURCE_ATTRIBUTE_TESTED,
>> > +MemoryBase,
>> > +MemorySize
>> > +);
>> > +}
>> > +
>> > +/**
>> > +  Populate IO resources from FDT that not added to GCD by its
>> > +  driver in the DXE phase.
>> > +
>> > +  @param  FdtBase   Fdt base address
>> > +  @param  CompatibleCompatible string
>> > +
>> > +**/
>> > +STATIC
>> > +VOID
>> > +PopulateIoResources (
>> > +  VOID  *FdtBase,
>> > +  CONST CHAR8*  Compatible
>> > +  )
>> > +{
>> > +  UINT64  *Reg;
>> > +  INT32   Node, LenP;
>> > +
>> > +  Node = fdt_node_offset_by_compatible (FdtBase, -1, Compatible);
>> > +  while (Node != -FDT_ERR_NOTFOUND) {
>> > +Reg = (UINT64 *)fdt_getprop (FdtBase, Node, "reg", );
>> > +if (Reg) {
>> > +  ASSERT (LenP == (2 * sizeof (UINT64)));
>> > +  AddIoMemoryBaseSizeHob (SwapBytes64 (Reg[0]), SwapBytes64
>> (Reg[1]));
>> > +}
>> > +Node = fdt_node_offset_by_compatible (FdtBase, Node, Compatible);
>> > +  }
>> > +}
>> > +
>> >  /**
>> >@retval EFI_SUCCESSThe address of FDT is passed in HOB.
>> >EFI_UNSUPPORTEDCan't locate FDT.
>> > @@ -80,5 +137,10 @@ PlatformPeimInitialization (
>> >
>> >BuildFvHob (PcdGet32 (PcdOvmfDxeMemFvBase), PcdGet32
>> (PcdOvmfDxeMemFvSize));
>> >
>> > +  PopulateIoResources (Base, "ns16550a");
>> > +  PopulateIoResources (Base, "qemu,fw-cfg-mmio");
>> > +  PopulateIoResources (Base, "virtio,mmio");
>> > +  AddIoMemoryBaseSizeHob (PcdGet32 (PcdOvmfFdBaseAddress), PcdGet32
>> (PcdOvmfFirmwareFdSize));
>> > +
>> >return EFI_SUCCESS;
>> >  }
>> > diff --git a/OvmfPkg/RiscVVirt/Sec/SecMain.inf
>> b/OvmfPkg/RiscVVirt/Sec/SecMain.inf
>> > index 0e2a5785e8a4..75d5b74b3d3f 100644
>> > --- a/OvmfPkg/RiscVVirt/Sec/SecMain.inf
>> > +++ b/OvmfPkg/RiscVVirt/Sec/SecMain.inf
>> > @@ -62,6 +62,7 @@
>> >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
>> >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
>> >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
>> > +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize
>> >
>> >  [Guids]
>> >gFdtHobGuid
>> > --
>> > 2.25.1
>> >
>> >
>> >
>> > 
>> > Groups.io Links: You receive all messages sent to this group.
>> > View/Reply Online (#105346):
>> https://edk2.groups.io/g/devel/message/105346
>> > Mute This Topic: https://groups.io/mt/9916/1131722
>> > Group Owner: devel+ow...@edk2.groups.io
>> > Unsubscribe: https://edk2.groups.io/g/devel/unsub [a...@kernel.org]
>> > 
>> >
>> >
>>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106288): https://edk2.groups.io/g/devel/message/106288
Mute This Topic: https://groups.io/mt/9916/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 0/2] Support MM based variable services in PEI for ARM

2023-06-22 Thread Kun Qin 

Thanks a lot, Sami!

On 6/22/2023 12:06 AM, Sami Mujawar wrote:

Hi Kun,

Apologies for the delay in reviewing.
I will take a look at this series shortly and get back.

Regards,

Sami Mujawar

On 22/06/2023, 06:07, "Kun Qin" mailto:kuqi...@gmail.com>> 
wrote:


Hi Arm and MdeModule package maintainers,


This patch series has been sent out for almost 2 weeks without any reviews.


Could you please provide feedback on the change when you have a chance?
Any input is appreciated.


Regards,
Kun


On 6/8/2023 1:44 PM, Kun Qin via groups.io wrote:

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


As of today, there has been a void in the variable service in PEI phase
on ARM systems that support PEI phase and standalone MM hosted variable
service.

This change adds the support through:
1. Add MM communication services in PEI phase for ARM platforms. This
module is based on SMC calls to standalone MM environments, similar to
"ArmPkg/Drivers/MmCommunicationDxe".

2. A service module that installs `gEfiPeiReadOnlyVariable2PpiGuid` based
on step 1. Note that this driver will not have special dependency on ARM
specific code, thus will be ideally added to MdeModulePkg.

Patch v1 branch: https://github.com/kuqin12/edk2/tree/arm_var_pei_v1 


Cc: Hao A Wu mailto:hao.a...@intel.com>>
Cc: Liming Gao mailto:gaolim...@byosoft.com.cn>>
Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
Cc: Leif Lindholm mailto:quic_llind...@quicinc.com>>
Cc: Ard Biesheuvel mailto:ardb+tianoc...@kernel.org>>
Cc: Sami Mujawar mailto:sami.muja...@arm.com>>

Kun Qin (2):
ArmPkg: MmCommunicationPei: Introduce MM communicate in PEI
MdeModulePkg: Variable: Introduce MM based variable read service in
PEI

ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.c | 178 +
MdeModulePkg/Universal/Variable/MmVariablePei/MmVariablePei.c | 381 

ArmPkg/ArmPkg.dsc | 2 +
ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.h | 76 
ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.inf | 41 +++
MdeModulePkg/MdeModulePkg.dsc | 1 +
MdeModulePkg/Universal/Variable/MmVariablePei/MmVariablePei.h | 134 +++
MdeModulePkg/Universal/Variable/MmVariablePei/MmVariablePei.inf | 43 +++
8 files changed, 856 insertions(+)
create mode 100644 ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.c
create mode 100644 MdeModulePkg/Universal/Variable/MmVariablePei/MmVariablePei.c
create mode 100644 ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.h
create mode 100644 ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.inf
create mode 100644 MdeModulePkg/Universal/Variable/MmVariablePei/MmVariablePei.h
create mode 100644 
MdeModulePkg/Universal/Variable/MmVariablePei/MmVariablePei.inf







-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106287): https://edk2.groups.io/g/devel/message/106287
Mute This Topic: https://groups.io/mt/99415823/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2 PATCH] MdePkg: Use same ProcessorBind symbol define for RISCV64

2023-06-22 Thread Xue, Gavin 
Hi Pedro,

Thanks for your feedback.

The sample code what I listed in last mail is from/owned by another team, and I 
didn't find other special #ifndef case for RSIC-V building so far.
RISC-V is an new processor architecture in edk2 implementation, in our internal 
BIOS code, there are many similar common code for edk2 and Windows app (for 
simulation).
It's better if we can reuse existing code (mostly are from x86) and minimize 
modifications as much as possible. So I think use same guard name is make sense.
How about your comments? Thanks.

Best regards,
Gavin

-Original Message-
From: Pedro Falcato  
Sent: Wednesday, June 21, 2023 10:16 PM
To: Xue, Gavin 
Cc: devel@edk2.groups.io; suni...@ventanamicro.com; Warkentin, Andrei 
; Wang, Yimin ; Sheng, Alan 

Subject: Re: [edk2-devel] [edk2 PATCH] MdePkg: Use same ProcessorBind symbol 
define for RISCV64

On Fri, Jun 16, 2023 at 4:52 PM Xue, Gavin  wrote:
>
> Hi Sunil/Pedro,
>
> 1. As you know, ProcessorBind.h file of CPU Architecture file declares sets 
> of base types for edk2 code compiling.
> So data type in edk2 code doesn't rely on specific compiler (msvc, gcc etc.), 
> which is a good design.
>
> But in practice, for the purpose of reuse, some code can be built with edk2, 
> and also can be built to a standalone application (e.g. Win App).
> Just like below code piece:
> ===
> #ifndef __WRAPPER_BASE_TYPES_H__
> #define __WRAPPER_BASE_TYPES_H__
>
> //
> // To avoid definition conflict during EDK2 build, it must include
> // ProcessorBind.h before xxx.h
> //
> #ifndef __PROCESSOR_BIND_H__
>
> #include 
> typedef uint8_t  UINT8;
> ==
>
> In this case, if this is a edk2 build, the code will refer to data types from 
> ProcessorBind.h, otherwise, it will refer to stdint.h from compiler.
>
> 2. Regarding the guard name, it's same __PROCESSOR_BIND_H__ macro in 
> AArch64/Arm/Ebc/Ia32/X64, but it is PROCESSOR_BIND_H_
> in RiscV64 and LoongArh64. For above code, if we build BIOS for RISCV64, it 
> will try to include stdint.h due to different guard name.
>
> I am not sure if we can use same guard name to keep code alignment, or give 
> some comments. Thanks.

Hi,
Hmm, interesting problem. Have you tried to #ifndef with some other
define? Like, I don't know, MAX_UINTN or EFIAPI?

-- 
Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106286): https://edk2.groups.io/g/devel/message/106286
Mute This Topic: https://groups.io/mt/99567569/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/1] Add support for running shell test application in an immutable volume

2023-06-22 Thread Kun Qin 
Also, a gentle ping on this topic. Could any maintainer help reviewing 
this change?


Any feedback is appreciated.

Regards,
Kun

On 6/6/2023 6:07 PM, Kun Qin via groups.io wrote:

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

This is a follow-up of a previously submitted patch series based on top
of master branch: https://edk2.groups.io/g/devel/message/105514.

The main changes between v1 and v2 patch are:
   - Added input argument support at library entrypoint.

The updated changes are verified on QEMU based Q35 virtual platform as
well as proprietary physical platforms.

Patch v2 branch: https://github.com/kuqin12/edk2/tree/unit_test_fv_v2

Cc: Michael D Kinney 
Cc: Michael Kubacki 
Cc: Sean Brogan 

Kun Qin (1):
   UnitTestFrameworkPkg: UnitTestPersistenceLib: Save Unit Test Cache
 Option

  
UnitTestFrameworkPkg/Library/UnitTestPersistenceLibSimpleFileSystem/UnitTestPersistenceLibSimpleFileSystem.c
 | 232 +---
  1 file changed, 157 insertions(+), 75 deletions(-)




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106285): https://edk2.groups.io/g/devel/message/106285
Mute This Topic: https://groups.io/mt/99376207/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2 PATCH] MdePkg: Use same ProcessorBind symbol define for RISCV64

2023-06-22 Thread Pedro Falcato 
On Thu, Jun 22, 2023 at 10:59 AM Xue, Gavin  wrote:
>
> Hi Pedro,
>
> Thanks for your feedback.
>
> The sample code what I listed in last mail is from/owned by another team, and 
> I didn't find other special #ifndef case for RSIC-V building so far.
> RISC-V is an new processor architecture in edk2 implementation, in our 
> internal BIOS code, there are many similar common code for edk2 and Windows 
> app (for simulation).
> It's better if we can reuse existing code (mostly are from x86) and minimize 
> modifications as much as possible. So I think use same guard name is make 
> sense.
> How about your comments? Thanks.

+CC Mike K

I (personally) would oppose this change. The specific include guard's
name is an implementation detail that should not be relied upon by the
header's consumers. In my view, your code should just get fixed.
The ideas I put out should still work for any CPU arch (even if hacky;
ideally, you would just set some sort of IS_EFI macro when building).

Mike, any opinion on this matter?

-- 
Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106284): https://edk2.groups.io/g/devel/message/106284
Mute This Topic: https://groups.io/mt/99567569/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/3] UefiCpuPkg/ResetVector: Remove pre-built binaries

2023-06-22 Thread Dong, Eric 
Reviewed-by: Eric Dong 

-Original Message-
From: Ni, Ray  
Sent: Wednesday, June 21, 2023 2:01 PM
To: Liu, Zhiguang ; Dong, Eric 
Cc: devel@edk2.groups.io; Ni, Ray 
Subject: RE: [edk2-devel] [PATCH v2 0/3] UefiCpuPkg/ResetVector: Remove 
pre-built binaries

I updated the patch per Zhiguang's comments to remove ALIGN 16 requirement.
Can you please review again?

Only the 2nd patch is updated.

Thanks,
Ray

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ni, Ray
> Sent: Wednesday, June 21, 2023 10:55 AM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH v2 0/3] UefiCpuPkg/ResetVector: Remove 
> pre- built binaries
> 
> Ray Ni (3):
>   UefiCpuPkg: Include ResetVector in DSC
>   UefiCpuPkg/ResetVector: Add guidance of FDF ffs rule
>   UefiCpuPkg/ResetVector: Remove pre-built binaries
> 
>  .../Vtf0/Bin/IA32/ResetVector.ia32.port80.raw | Bin 532 -> 0 bytes
>  .../Vtf0/Bin/IA32/ResetVector.ia32.raw| Bin 500 -> 0 bytes
>  .../Vtf0/Bin/IA32/ResetVector.ia32.serial.raw | Bin 900 -> 0 bytes
>  .../ResetVector/Vtf0/Bin/ResetVector.inf  |  31 --
>  .../ResetVector/Vtf0/Bin/ResetVector.uni  |  16 
>  .../ResetVector/Vtf0/Bin/ResetVector1G.inf|  31 --
>  .../ResetVector/Vtf0/Bin/ResetVectorExtra.uni |  12 ---
>  .../PageTable1G/ResetVector.x64.port80.raw| Bin 12292 -> 0 bytes
>  .../Bin/X64/PageTable1G/ResetVector.x64.raw   | Bin 12292 -> 0 bytes
>  .../PageTable1G/ResetVector.x64.serial.raw| Bin 12292 -> 0 bytes
>  .../PageTable2M/ResetVector.x64.port80.raw| Bin 28676 -> 0 bytes
>  .../Bin/X64/PageTable2M/ResetVector.x64.raw   | Bin 28676 -> 0 bytes
>  .../PageTable2M/ResetVector.x64.serial.raw| Bin 28676 -> 0 bytes
>  UefiCpuPkg/ResetVector/Vtf0/Build.py  |  89 --
>  UefiCpuPkg/ResetVector/Vtf0/ReadMe.txt|  27 ++
>  .../Vtf0/Tools/FixupForRawSection.py  |  20 
>  UefiCpuPkg/ResetVector/Vtf0/Vtf0.inf  |  28 +-
>  UefiCpuPkg/UefiCpuPkg.dsc |   4 +-
>  18 files changed, 36 insertions(+), 222 deletions(-)  delete mode 
> 100644 
> UefiCpuPkg/ResetVector/Vtf0/Bin/IA32/ResetVector.ia32.port80.raw
>  delete mode 100644
> UefiCpuPkg/ResetVector/Vtf0/Bin/IA32/ResetVector.ia32.raw
>  delete mode 100644
> UefiCpuPkg/ResetVector/Vtf0/Bin/IA32/ResetVector.ia32.serial.raw
>  delete mode 100644 UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.inf
>  delete mode 100644 UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.uni
>  delete mode 100644 UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector1G.inf
>  delete mode 100644
> UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVectorExtra.uni
>  delete mode 100644
> UefiCpuPkg/ResetVector/Vtf0/Bin/X64/PageTable1G/ResetVector.x64.port80
> .raw
>  delete mode 100644
> UefiCpuPkg/ResetVector/Vtf0/Bin/X64/PageTable1G/ResetVector.x64.raw
>  delete mode 100644
> UefiCpuPkg/ResetVector/Vtf0/Bin/X64/PageTable1G/ResetVector.x64.serial
> .r
> aw
>  delete mode 100644
> UefiCpuPkg/ResetVector/Vtf0/Bin/X64/PageTable2M/ResetVector.x64.port8
> 0.raw
>  delete mode 100644
> UefiCpuPkg/ResetVector/Vtf0/Bin/X64/PageTable2M/ResetVector.x64.raw
>  delete mode 100644
> UefiCpuPkg/ResetVector/Vtf0/Bin/X64/PageTable2M/ResetVector.x64.serial
> .r
> aw
>  delete mode 100644 UefiCpuPkg/ResetVector/Vtf0/Build.py
>  delete mode 100644
> UefiCpuPkg/ResetVector/Vtf0/Tools/FixupForRawSection.py
> 
> --
> 2.39.1.windows.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106283): https://edk2.groups.io/g/devel/message/106283
Mute This Topic: https://groups.io/mt/99669680/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 1/1] CI: Use latest image for Linux jobs (Qemu 8, gcc 12)

2023-06-22 Thread Oliver Steffen 
Use the latest Linux container image (from 2023-05-30).
It uses Qemu 8.0.0 and gcc 12.

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

Signed-off-by: Oliver Steffen 
Acked-by: Ard Biesheuvel 
Reviewed-by: Michael Kubacki 
---
 .azurepipelines/templates/defaults.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.azurepipelines/templates/defaults.yml 
b/.azurepipelines/templates/defaults.yml
index 6730a0e8e4b3..8006495580f3 100644
--- a/.azurepipelines/templates/defaults.yml
+++ b/.azurepipelines/templates/defaults.yml
@@ -9,4 +9,4 @@
 
 variables:
   default_python_version: ">=3.10.6"
-  default_linux_image: "ghcr.io/tianocore/containers/fedora-37-test:3b3eb8f"
+  default_linux_image: "ghcr.io/tianocore/containers/fedora-37-test:a0dd931"
-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106282): https://edk2.groups.io/g/devel/message/106282
Mute This Topic: https://groups.io/mt/99695649/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 0/1] CI: Use latest image for Linux jobs (Qemu 8, gcc 12)

2023-06-22 Thread Oliver Steffen 
Use the latest Linux container image (from 2023-05-30).
It uses Qemu 8.0.0 and gcc 12.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4324
PR: https://github.com/tianocore/edk2/pull/4460

v2:
- Collect RBs and Acks
- Rerun CI with current master branch

v1:
- intial version

Oliver Steffen (1):
  CI: Use latest image for Linux jobs (Qemu 8, gcc 12)

 .azurepipelines/templates/defaults.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106281): https://edk2.groups.io/g/devel/message/106281
Mute This Topic: https://groups.io/mt/99695648/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/1] NetworkPkg/IScsiDxe: add checks to IScsiBuildKeyValueList

2023-06-22 Thread Gerd Hoffmann 
Check we have any data left (Len > 0) before advancing the Data pointer
and reducing Len.  Avoids wrapping Len.

Also replace the AsciiStrLen() call with an open-coded loop which
likewise checks Len to make sure we don't overrun the buffer.

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4207
Reported-by: Jeremy Boone 
Signed-off-by: Gerd Hoffmann 
---
 NetworkPkg/IScsiDxe/IScsiProto.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/NetworkPkg/IScsiDxe/IScsiProto.c b/NetworkPkg/IScsiDxe/IScsiProto.c
index ef587649a05e..88e7946d3f78 100644
--- a/NetworkPkg/IScsiDxe/IScsiProto.c
+++ b/NetworkPkg/IScsiDxe/IScsiProto.c
@@ -1903,9 +1903,8 @@ IScsiBuildKeyValueList (
   Data++;
 }
 
-if (*Data == '=') {
+if ((Len > 0) && (*Data == '=')) {
   *Data = '\0';
-
   Data++;
   Len--;
 } else {
@@ -1917,8 +1916,17 @@ IScsiBuildKeyValueList (
 
 InsertTailList (ListHead, >List);
 
-Data += AsciiStrLen (KeyValuePair->Value) + 1;
-Len  -= (UINT32)AsciiStrLen (KeyValuePair->Value) + 1;
+while ((Len > 0) && (*Data != '\0')) {
+  Len--;
+  Data++;
+}
+
+if ((Len > 0) && (*Data == '\0')) {
+  Data++;
+  Len--;
+} else {
+  goto ON_ERROR;
+}
   }
 
   return ListHead;
-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106280): https://edk2.groups.io/g/devel/message/106280
Mute This Topic: https://groups.io/mt/99694846/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] SecurityPkg/SecureBoot: Support RSA 512 and RSA 384

2023-06-22 Thread Yao, Jiewen 
Thank you very much to contribute this patch. Here is my feedback.

1) I don't believe that you cannot use digest size to determine the algorithm, 
because different hash algorithm may have same time. E.g. SHA256 and SHA3_256.

+  if (DigestSize == SHA256_DIGEST_SIZE) {
+Status = CalculatePrivAuthVarSignChainSHA256Digest (
+   SignerCert,
+   SignerCertSize,
+   TopLevelCert,
+   TopLevelCertSize,
+   ShaDigest
+   );

2) I don't believe that you cannot assuming CtxSize of SHA512 is bigger than 
SHA256. I think we may need create context for each algo.

@@ -135,7 +135,7 @@ AuthVariableLibInitialize (
   //
   // Initialize hash context.
   //
-  CtxSize  = Sha256GetContextSize ();
+  CtxSize  = Sha512GetContextSize ();
   mHashCtx = AllocateRuntimePool (CtxSize);
   if (mHashCtx == NULL) {

3) I believe we should use 0 for SHA256 and ASSERT in default.

+  switch (PcdGet8 (PcdSecureBootDefaultHashAlg)) {
+  case 1:
+DEBUG ((DEBUG_INFO, "%a use SHA384", __func__));
+HashAlg = HASHALG_SHA384;
+break;
+  case 2:
+DEBUG ((DEBUG_INFO, "%a use SHA512", __func__));
+HashAlg = HASHALG_SHA512;
+break;
+  default:
+DEBUG ((DEBUG_INFO, "%a use SHA256", __func__));
+HashAlg = HASHALG_SHA256;
+break;
+  }

4) I am not sure why we need this PCD. Why cannot we support all of hash algo?

+  ## Indicates default hash algorithm in Secure Boot
+  #   0 - Use SHA256
+  #   1 - Use SHA384
+  #   2 - Use SHA512
+  # @Prompt Secure Boot default hash algorithm
+  gEfiSecurityPkgTokenSpaceGuid.PcdSecureBootDefaultHashAlg|0|UINT8|0x00010040

5) I don't believe that you can use size to determine the algorithm. We need a 
more robust way, such as algorithm ID.

+  switch (KeyLenInBytes) {
+  case WIN_CERT_UEFI_RSA2048_SIZE:
+CopyGuid (>SignatureType, );
+break;
+  case WIN_CERT_UEFI_RSA3072_SIZE:
+CopyGuid (>SignatureType, );
+break;
+  case WIN_CERT_UEFI_RSA4096_SIZE:
+CopyGuid (>SignatureType, );
+break;
+break;

Thank you
Yao, Jiewen

> -Original Message-
> From: Sheng, W 
> Sent: Thursday, May 25, 2023 1:23 PM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Wang, Jian J ;
> Xu, Min M ; Chen, Zeyi ; Wang,
> Fiona 
> Subject: [PATCH] SecurityPkg/SecureBoot: Support RSA 512 and RSA 384
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3413
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Min Xu 
> Cc: Zeyi Chen 
> Cc: Fiona Wang 
> Signed-off-by: Sheng Wei 
> ---
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c   |   3 +-
>  MdePkg/Include/Guid/ImageAuthentication.h |  26 ++
>  MdePkg/MdePkg.dec |   2 +
>  .../Library/AuthVariableLib/AuthService.c | 272 --
>  .../Library/AuthVariableLib/AuthVariableLib.c |   4 +-
>  .../DxeImageVerificationLib.c |  35 ++-
>  .../DxeImageVerificationLib.inf   |   1 +
>  SecurityPkg/SecurityPkg.dec   |   7 +
>  .../SecureBootConfigDxe.inf   |  19 ++
>  .../SecureBootConfigImpl.c| 122 +++-
>  .../SecureBootConfigImpl.h|   2 +
>  .../SecureBootConfigStrings.uni   |   6 +
>  12 files changed, 463 insertions(+), 36 deletions(-)
> 
> diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c
> b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c
> index 027dbb6842..944bcf8d38 100644
> --- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c
> +++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c
> @@ -591,7 +591,8 @@ ImageTimestampVerify (
>// Register & Initialize necessary digest algorithms for PKCS#7 Handling.
> 
>//
> 
>if ((EVP_add_digest (EVP_md5 ()) == 0) || (EVP_add_digest (EVP_sha1 ()) == 
> 0)
> ||
> 
> -  (EVP_add_digest (EVP_sha256 ()) == 0) || ((EVP_add_digest_alias
> (SN_sha1WithRSAEncryption, SN_sha1WithRSA)) == 0))
> 
> +  (EVP_add_digest (EVP_sha256 ()) == 0) || (EVP_add_digest (EVP_sha384 
> ())
> == 0) ||
> 
> +  (EVP_add_digest (EVP_sha512 ()) == 0) || ((EVP_add_digest_alias
> (SN_sha1WithRSAEncryption, SN_sha1WithRSA)) == 0))
> 
>{
> 
>  return FALSE;
> 
>}
> 
> diff --git a/MdePkg/Include/Guid/ImageAuthentication.h
> b/MdePkg/Include/Guid/ImageAuthentication.h
> index fe83596571..c8ea2c14fb 100644
> --- a/MdePkg/Include/Guid/ImageAuthentication.h
> +++ b/MdePkg/Include/Guid/ImageAuthentication.h
> @@ -144,6 +144,30 @@ typedef struct {
>  0x3c5766e8, 0x269c, 0x4e34, {0xaa, 0x14, 0xed, 0x77, 0x6e, 0x85, 0xb3,
> 0xb6} \
> 
>}
> 
> 
> 
> +///
> 
> +/// This identifies a signature containing an RSA-3072 key. The key (only the
> modulus
> 
> +/// since the public key exponent is known to be 0x10001) shall be stored in 
> big-
> endian
> 
> +/// order.
> 
> +/// The SignatureHeader size shall always be 0. The SignatureSize shall 
> always
> be 16 (size
> 
> +/// of SignatureOwner component) + 384 bytes.
> 
> +///
> 
> +#define EFI_CERT_RSA3072_GUID \
> 
>

Re: [edk2-devel] [PATCH v1 0/2] Support MM based variable services in PEI for ARM

2023-06-22 Thread Sami Mujawar 
Hi Kun,

Apologies for the delay in reviewing.
I will take a look at this series shortly and get back.

Regards,

Sami Mujawar

On 22/06/2023, 06:07, "Kun Qin" mailto:kuqi...@gmail.com>> 
wrote:


Hi Arm and MdeModule package maintainers,


This patch series has been sent out for almost 2 weeks without any reviews.


Could you please provide feedback on the change when you have a chance?
Any input is appreciated.


Regards,
Kun


On 6/8/2023 1:44 PM, Kun Qin via groups.io wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4464 
> 
>
> As of today, there has been a void in the variable service in PEI phase
> on ARM systems that support PEI phase and standalone MM hosted variable
> service.
>
> This change adds the support through:
> 1. Add MM communication services in PEI phase for ARM platforms. This
> module is based on SMC calls to standalone MM environments, similar to
> "ArmPkg/Drivers/MmCommunicationDxe".
>
> 2. A service module that installs `gEfiPeiReadOnlyVariable2PpiGuid` based
> on step 1. Note that this driver will not have special dependency on ARM
> specific code, thus will be ideally added to MdeModulePkg.
>
> Patch v1 branch: https://github.com/kuqin12/edk2/tree/arm_var_pei_v1 
> 
>
> Cc: Hao A Wu mailto:hao.a...@intel.com>>
> Cc: Liming Gao mailto:gaolim...@byosoft.com.cn>>
> Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
> Cc: Leif Lindholm  >
> Cc: Ard Biesheuvel  >
> Cc: Sami Mujawar mailto:sami.muja...@arm.com>>
>
> Kun Qin (2):
> ArmPkg: MmCommunicationPei: Introduce MM communicate in PEI
> MdeModulePkg: Variable: Introduce MM based variable read service in
> PEI
>
> ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.c | 178 +
> MdeModulePkg/Universal/Variable/MmVariablePei/MmVariablePei.c | 381 
> 
> ArmPkg/ArmPkg.dsc | 2 +
> ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.h | 76 
> ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.inf | 41 +++
> MdeModulePkg/MdeModulePkg.dsc | 1 +
> MdeModulePkg/Universal/Variable/MmVariablePei/MmVariablePei.h | 134 +++
> MdeModulePkg/Universal/Variable/MmVariablePei/MmVariablePei.inf | 43 +++
> 8 files changed, 856 insertions(+)
> create mode 100644 ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.c
> create mode 100644 
> MdeModulePkg/Universal/Variable/MmVariablePei/MmVariablePei.c
> create mode 100644 ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.h
> create mode 100644 ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.inf
> create mode 100644 
> MdeModulePkg/Universal/Variable/MmVariablePei/MmVariablePei.h
> create mode 100644 
> MdeModulePkg/Universal/Variable/MmVariablePei/MmVariablePei.inf
>





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106278): https://edk2.groups.io/g/devel/message/106278
Mute This Topic: https://groups.io/mt/99415823/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-