Date   

Re: [PATCH] [EmbeddedPkg]:Update PrePiLib to return DxeCoreEntrypoint

Guo Dong
 

Hi Leif and Biesheuvel,

Could you help review this patch?

Thanks,
Guo

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Guo Dong
Sent: Saturday, August 1, 2020 4:53 PM
To: devel@edk2.groups.io
Cc: leif@...; ard.biesheuvel@...
Subject: [edk2-devel] [PATCH] [EmbeddedPkg]:Update PrePiLib to return
DxeCoreEntrypoint

Added LoadDxeCore() API to return DxeCore entry point after loading DxeCore
from FV, and del LoadDxeCoreFromFfsFile() as it is replaced by LoadDxeCore().
Update LoadDxeCoreFromFv() to use LoadDxeCore() to reduce code, and its
behavior is same.
Updated FfsProcessSection() to support both IA32 and X64 build.
With this patch, PrePiLib could be used by UefiPayloadPkg to load DxeCore
and get its entry point.

Signed-off-by: Guo Dong <guo.dong@...>
---
EmbeddedPkg/Include/Library/PrePiLib.h | 17 ++++++++++++++---
EmbeddedPkg/Library/PrePiLib/FwVol.c | 2 +-
EmbeddedPkg/Library/PrePiLib/PrePiLib.c | 95
+++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------
-----------------------
3 files changed, 68 insertions(+), 46 deletions(-)

diff --git a/EmbeddedPkg/Include/Library/PrePiLib.h
b/EmbeddedPkg/Include/Library/PrePiLib.h
index 54f8e1e582..269907108e 100644
--- a/EmbeddedPkg/Include/Library/PrePiLib.h
+++ b/EmbeddedPkg/Include/Library/PrePiLib.h
@@ -735,11 +735,22 @@ LoadPeCoffImage (
OUT EFI_PHYSICAL_ADDRESS *EntryPoint
);

+
+/**
+ Load DXE core from FV and return DXE core entrypoint.
+
+ @param[in] FvInstance The FV instance to search DXE core. Will search
all the FVs if it is NULL.
+ @param[out] EntryPoint DXE core entrypoint.
+
+ @return EFI_SUCCESS The DxeCore is loaded successfully.
+ @return Others Failed to load the DxeCore.
+
+**/
EFI_STATUS
EFIAPI
-LoadDxeCoreFromFfsFile (
- IN EFI_PEI_FILE_HANDLE FileHandle,
- IN UINTN StackSize
+LoadDxeCore (
+ IN UINTN *FvInstance, OPTIONAL
+ OUT EFI_PHYSICAL_ADDRESS *EntryPoint
);

EFI_STATUS
diff --git a/EmbeddedPkg/Library/PrePiLib/FwVol.c
b/EmbeddedPkg/Library/PrePiLib/FwVol.c
index 881506eddd..46ea5f733f 100644
--- a/EmbeddedPkg/Library/PrePiLib/FwVol.c
+++ b/EmbeddedPkg/Library/PrePiLib/FwVol.c
@@ -298,7 +298,7 @@ FfsProcessSection (
UINT16 SectionAttribute;
UINT32 AuthenticationStatus;
CHAR8 *CompressedData;
- UINTN CompressedDataLength;
+ UINT32 CompressedDataLength;


*OutputBuffer = NULL;
diff --git a/EmbeddedPkg/Library/PrePiLib/PrePiLib.c
b/EmbeddedPkg/Library/PrePiLib/PrePiLib.c
index afbe146632..c18b30e22e 100644
--- a/EmbeddedPkg/Library/PrePiLib/PrePiLib.c
+++ b/EmbeddedPkg/Library/PrePiLib/PrePiLib.c
@@ -119,30 +119,52 @@ VOID
IN VOID *HobStart
);

+/**
+ Load DXE core from FV and return DXE core entrypoint.
+
+ @param[in] FvInstance The FV instance to search DXE core. Will search
all the FVs if it is NULL.
+ @param[out] EntryPoint DXE core entrypoint.
+
+ @return EFI_SUCCESS The DxeCore is loaded successfully.
+ @return Others Failed to load the DxeCore.
+
+**/
EFI_STATUS
EFIAPI
-LoadDxeCoreFromFfsFile (
- IN EFI_PEI_FILE_HANDLE FileHandle,
- IN UINTN StackSize
+LoadDxeCore (
+ IN UINTN *FvInstance, OPTIONAL
+ OUT EFI_PHYSICAL_ADDRESS *EntryPoint
)
{
EFI_STATUS Status;
+ EFI_PEI_FV_HANDLE VolumeHandle;
+ EFI_PEI_FILE_HANDLE FileHandle;
VOID *PeCoffImage;
EFI_PHYSICAL_ADDRESS ImageAddress;
UINT64 ImageSize;
- EFI_PHYSICAL_ADDRESS EntryPoint;
- VOID *BaseOfStack;
- VOID *TopOfStack;
- VOID *Hob;
EFI_FV_FILE_INFO FvFileInfo;

+ FileHandle = NULL;
+ if (FvInstance != NULL) {
+ //
+ // Caller passed in a specific FV to try, so only try that one
+ //
+ Status = FfsFindNextVolume (*FvInstance, &VolumeHandle);
+ if (!EFI_ERROR (Status)) {
+ Status = FfsFindNextFile (EFI_FV_FILETYPE_DXE_CORE, VolumeHandle,
&FileHandle);
+ }
+ } else {
+ Status = FfsAnyFvFindFirstFile (EFI_FV_FILETYPE_DXE_CORE,
&VolumeHandle, &FileHandle);
+ DEBUG ((EFI_D_ERROR, "FfsAnyFvFindFirstFile Status = %r\n", Status));
+ }
+
Status = FfsFindSectionData (EFI_SECTION_PE32, FileHandle, &PeCoffImage);
if (EFI_ERROR (Status)) {
return Status;
}


- Status = LoadPeCoffImage (PeCoffImage, &ImageAddress, &ImageSize,
&EntryPoint);
+ Status = LoadPeCoffImage (PeCoffImage, &ImageAddress, &ImageSize,
EntryPoint);
// For NT32 Debug Status = SecWinNtPeiLoadFile (PeCoffImage,
&ImageAddress, &ImageSize, &EntryPoint);
ASSERT_EFI_ERROR (Status);

@@ -152,13 +174,33 @@ LoadDxeCoreFromFfsFile (
Status = FfsGetFileInfo (FileHandle, &FvFileInfo);
ASSERT_EFI_ERROR (Status);

- BuildModuleHob (&FvFileInfo.FileName,
(EFI_PHYSICAL_ADDRESS)(UINTN)ImageAddress, EFI_SIZE_TO_PAGES ((UINT32)
ImageSize) * EFI_PAGE_SIZE, EntryPoint);
+ BuildModuleHob (&FvFileInfo.FileName,
(EFI_PHYSICAL_ADDRESS)(UINTN)ImageAddress, EFI_SIZE_TO_PAGES ((UINT32)
ImageSize) * EFI_PAGE_SIZE, *EntryPoint);

- DEBUG ((EFI_D_INFO | EFI_D_LOAD, "Loading DxeCore at 0x%10p
EntryPoint=0x%10p\n", (VOID *)(UINTN)ImageAddress, (VOID
*)(UINTN)EntryPoint));
+ DEBUG ((EFI_D_INFO | EFI_D_LOAD, "Loading DxeCore at 0x%10p
EntryPoint=0x%10p\n", (VOID *)(UINTN)ImageAddress, (VOID
*)(UINTN)*EntryPoint));
+
+ return EFI_SUCCESS;
+}
+
+
+EFI_STATUS
+EFIAPI
+LoadDxeCoreFromFv (
+ IN UINTN *FvInstance, OPTIONAL
+ IN UINTN StackSize
+ )
+{
+ EFI_STATUS Status;
+ EFI_PHYSICAL_ADDRESS EntryPoint;
+ VOID *BaseOfStack;
+ VOID *TopOfStack;
+ VOID *Hob;
+
+ Status = LoadDxeCore (FvInstance, &EntryPoint);
+ ASSERT_EFI_ERROR (Status);

Hob = GetHobList ();
if (StackSize == 0) {
- // User the current stack
+ // Use the current stack

((DXE_CORE_ENTRY_POINT)(UINTN)EntryPoint) (Hob);
} else {
@@ -199,37 +241,6 @@ LoadDxeCoreFromFfsFile (



-EFI_STATUS
-EFIAPI
-LoadDxeCoreFromFv (
- IN UINTN *FvInstance, OPTIONAL
- IN UINTN StackSize
- )
-{
- EFI_STATUS Status;
- EFI_PEI_FV_HANDLE VolumeHandle;
- EFI_PEI_FILE_HANDLE FileHandle = NULL;
-
- if (FvInstance != NULL) {
- //
- // Caller passed in a specific FV to try, so only try that one
- //
- Status = FfsFindNextVolume (*FvInstance, &VolumeHandle);
- if (!EFI_ERROR (Status)) {
- Status = FfsFindNextFile (EFI_FV_FILETYPE_DXE_CORE, VolumeHandle,
&FileHandle);
- }
- } else {
- Status = FfsAnyFvFindFirstFile (EFI_FV_FILETYPE_DXE_CORE,
&VolumeHandle, &FileHandle);
- }
-
- if (!EFI_ERROR (Status)) {
- return LoadDxeCoreFromFfsFile (FileHandle, StackSize);
- }
-
- return Status;
-}
-
-
EFI_STATUS
EFIAPI
DecompressFirstFv (
--
2.16.2.windows.1



Re: Patch to improve DNS answers parser

Laszlo Ersek
 

On 08/26/20 18:24, Leandro G. B. Becker wrote:
Hello folks,

I made an improvement to DNS client (DnsImpl.c, line 1392) that instead of abort processing answer records when a record that is not of type PTR is received, skip the record and goes to the next one if there is one. I had a problem while resolving some names when DNS receives more than one answer and the first one is not of type 0xC0 (PTR) and now it is working fine.

So to submit the patch for review is through this e-mail group, following the instructions at https://github.com/tianocore/edk2, section "Code Contributions"?
Yes please!

See also the official description at:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

and if you care for a very long & unofficial one:

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

When you post the patch for NetworkPkg, please CC the NetworkPkg reviewers / maintainers (see Maintainers.txt).

Thanks!
Laszlo


Re: [PATCH V2 2/2] BaseTools: Factorize GCC flags

Laszlo Ersek
 

On 07/22/20 13:03, Laszlo Ersek wrote:
Hi Pierre,

On 07/07/20 10:35, PierreGondois wrote:
From: Pierre Gondois <pierre.gondois@...>

GCC48_ALL_CC_FLAGS has no dependency on GCC_ALL_CC_FLAGS.
By definition, there should be such dependency.

The outcomes of this patch is that GCC48_ALL_CC_FLAGS and
other dependent configurations will inherit from the
additional "-Os" flag.
The "-Os" flag optimizes a build in size, not breaking any
build. In a gcc command line, the last optimization flag
has precedence. This means that this "-Os" flag will be
overriden by a more specific optimization configuration,
provided that this more specific flag is appended at the
end of the CC_FLAGS.

Signed-off-by: Pierre Gondois <pierre.gondois@...>
Suggested-by: Tomas Pilar <Tomas.Pilar@...>
---

The changes can be seen at: https://github.com/PierreARM/edk2/commits/831_Add_gcc_flag_warning_v2

Notes:
v2:
- Make GCC48_ALL_CC_FLAGS dependent on
GCC_ALL_CC_FLAGS. [Tomas]

BaseTools/Conf/tools_def.template | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
index 397b011ba38f97f81f314f8641ac8bb95d5a2197..a1fd27b1adba8769949b7d628d7fbed49fe24267 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -1952,7 +1952,7 @@ DEFINE GCC_RISCV64_RC_FLAGS = -I binary -O elf64-littleriscv -B riscv
# GCC Build Flag for included header file list generation
DEFINE GCC_DEPS_FLAGS = -MMD -MF $@.deps

-DEFINE GCC48_ALL_CC_FLAGS = -g -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h -fno-common -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
+DEFINE GCC48_ALL_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS) -ffunction-sections -fdata-sections -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
DEFINE GCC48_IA32_X64_DLINK_COMMON = -nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x20
DEFINE GCC48_IA32_CC_FLAGS = DEF(GCC48_ALL_CC_FLAGS) -m32 -march=i586 -malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables -Wno-address
DEFINE GCC48_X64_CC_FLAGS = DEF(GCC48_ALL_CC_FLAGS) -m64 -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -maccumulate-outgoing-args -mno-red-zone -Wno-address -mcmodel=small -fpie -fno-asynchronous-unwind-tables -Wno-address
As the commit message states, this change makes GCC48_ALL_CC_FLAGS inherit "-Os".

It is true that all the NOOPT_GCC flags override "-Os" with "-O0":

NOOPT_GCC48_IA32_CC_FLAGS = DEF(GCC48_IA32_CC_FLAGS) -O0
NOOPT_GCC48_X64_CC_FLAGS = DEF(GCC48_X64_CC_FLAGS) -O0
NOOPT_GCC48_ARM_CC_FLAGS = DEF(GCC48_ARM_CC_FLAGS) -O0
NOOPT_GCC48_AARCH64_CC_FLAGS = DEF(GCC48_AARCH64_CC_FLAGS) -O0
NOOPT_GCC49_IA32_CC_FLAGS = DEF(GCC49_IA32_CC_FLAGS) -O0
NOOPT_GCC49_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -O0
NOOPT_GCC49_ARM_CC_FLAGS = DEF(GCC49_ARM_CC_FLAGS) -O0
NOOPT_GCC49_AARCH64_CC_FLAGS = DEF(GCC49_AARCH64_CC_FLAGS) -O0
NOOPT_GCC5_IA32_CC_FLAGS = DEF(GCC5_IA32_CC_FLAGS) -O0
NOOPT_GCC5_X64_CC_FLAGS = DEF(GCC5_X64_CC_FLAGS) -O0
NOOPT_GCC5_ARM_CC_FLAGS = DEF(GCC5_ARM_CC_FLAGS) -O0
NOOPT_GCC5_AARCH64_CC_FLAGS = DEF(GCC5_AARCH64_CC_FLAGS) -O0

However, *some* of the DEBUG and RELEASE flags now have two "-Os" flags:

DEBUG_GCC48_IA32_CC_FLAGS = DEF(GCC48_IA32_CC_FLAGS) -Os
RELEASE_GCC48_IA32_CC_FLAGS = DEF(GCC48_IA32_CC_FLAGS) -Os -Wno-unused-but-set-variable
DEBUG_GCC48_X64_CC_FLAGS = DEF(GCC48_X64_CC_FLAGS) -Os
RELEASE_GCC48_X64_CC_FLAGS = DEF(GCC48_X64_CC_FLAGS) -Os -Wno-unused-but-set-variable
DEBUG_GCC49_IA32_CC_FLAGS = DEF(GCC49_IA32_CC_FLAGS) -Os
RELEASE_GCC49_IA32_CC_FLAGS = DEF(GCC49_IA32_CC_FLAGS) -Os -Wno-unused-but-set-variable -Wno-unused-const-variable
DEBUG_GCC49_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -Os
RELEASE_GCC49_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -Os -Wno-unused-but-set-variable -Wno-unused-const-variable
DEBUG_GCC5_IA32_CC_FLAGS = DEF(GCC5_IA32_CC_FLAGS) -flto -Os
RELEASE_GCC5_IA32_CC_FLAGS = DEF(GCC5_IA32_CC_FLAGS) -flto -Os -Wno-unused-but-set-variable -Wno-unused-const-variable
DEBUG_GCC5_X64_CC_FLAGS = DEF(GCC5_X64_CC_FLAGS) -flto -DUSING_LTO -Os
RELEASE_GCC5_X64_CC_FLAGS = DEF(GCC5_X64_CC_FLAGS) -flto -DUSING_LTO -Os -Wno-unused-but-set-variable -Wno-unused-const-variable

(The ARM and AARCH64 DEBUG/RELEASE GCC options don't seem to be affected, as they have relied on inherited -- not open-coded -- "-Os" options from much earlier. So now they do not suffer from this duplication.)

The point of this patch was a kind of "normalization", so I think the work isn't complete until the duplication is undone, i.e., the explicit "-Os" flag is removed from the last twelve defines.

Can you submit a follow-up patch please?
I have not received an answer, and I'm not aware of a follow-up patch
being on the list; so now I've filed:

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

Thanks
Laszlo


Patch to improve DNS answers parser

Leandro G. B. Becker
 

Hello folks,

 

I made an improvement to DNS client (DnsImpl.c, line 1392) that instead of abort processing answer records when a record that is not of type PTR is received, skip the record and goes to the next one if there is one. I had a problem while resolving some names when DNS receives more than one answer and the first one is not of type 0xC0 (PTR) and now it is working fine.

 

So to submit the patch for review is through this e-mail group, following the instructions at https://github.com/tianocore/edk2, section “Code Contributions”?

 

Thank you!

 

LEANDRO GUSTAVO BISS BECKER

Development Engineer

R&D - BIOS Development - Manaus

lbecker@...

Positivo Tecnologia

Tel.: +55 92  3183-7988

 

This message may contain confidential and/or legally privileged information. If you are not the intended recipient or the person authorized to receive this message, you must not use, copy or disclose the information contained herein or take any action based on this content, and you must notify the sender and delete the message permanently from your system.

Positivo Tecnologia seeks to ensure the highest level of corporate integrity and ethics in its activities, making available to all the “Canal Aberto”, through which anyone can report possible violations of internal policies, laws and regulations. The “Canal Aberto” can be accessed anonymously, anytime, through the website www.positivotecnologia.com.br/canalaberto or by calling 0800 727 7016.

 

 


Re: [PATCH v3 edk2-platforms 5/8] SbsaQemu: AcpiDxe: Create MADT table at runtime

graeme@...
 

On Tue, Aug 25, 2020 at 07:09:55PM +0530, Tanmay Jagdale wrote:
- Add support to create MADT table at runtime.
- Included a macro for GIC Redistributor structure initialisation.

Signed-off-by: Tanmay Jagdale <tanmay.jagdale@...>
---
Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf | 20 ++-
Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h | 15 ++
Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 156 ++++++++++++++++++++
3 files changed, 190 insertions(+), 1 deletion(-)

diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
index 3795a7e11639..8125e8ba7553 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
@@ -41,9 +41,27 @@ [LibraryClasses]
UefiRuntimeServicesTableLib

[Pcd]
+ gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiTableStorageFile
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdClusterCount
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress

[Depex]
- TRUE
+ gEfiAcpiTableProtocolGuid ## CONSUMES
+
+[Guids]
+ gEdkiiPlatformHasAcpiGuid
+
+[Protocols]
+ gEfiAcpiTableProtocolGuid ## CONSUMES
+
+[FixedPcd]
+ gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultOemRevision
+ gArmTokenSpaceGuid.PcdGicDistributorBase
+ gArmTokenSpaceGuid.PcdGicRedistributorsBase
+
+ gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorId
+ gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorRevision
+ gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultOemId
+ gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultOemTableId
+ gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultOemRevision
diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
index eac195b0585c..7a9a0061675f 100644
--- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
+++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
@@ -22,6 +22,21 @@
FixedPcdGet32 (PcdAcpiDefaultCreatorRevision)/* UINT32 CreatorRevision */ \
}

+// Defines for MADT
+#define SBSAQEMU_MADT_GIC_VBASE 0x2c020000
+#define SBSAQEMU_MADT_GIC_HBASE 0x2c010000
+#define SBSAQEMU_MADT_GIC_PMU_IRQ 23
+#define SBSAQEMU_MADT_GICR_SIZE 0x4000000
+
+// Macro for MADT GIC Redistributor Structure
+#define SBSAQEMU_MADT_GICR_INIT() { \
+ EFI_ACPI_6_0_GICR, /* Type */ \
+ sizeof (EFI_ACPI_6_0_GICR_STRUCTURE), /* Length */ \
+ EFI_ACPI_RESERVED_WORD, /* Reserved */ \
+ FixedPcdGet32 (PcdGicRedistributorsBase), /* DiscoveryRangeBaseAddress */ \
+ SBSAQEMU_MADT_GICR_SIZE /* DiscoveryRangeLength */ \
+ }
+
#define SBSAQEMU_UART0_BASE 0x60000000

#define SBSAQEMU_PCI_SEG0_CONFIG_BASE 0xf0000000
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index 75abdae3b8ce..16cb4e904e6f 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -6,11 +6,17 @@
* SPDX-License-Identifier: BSD-2-Clause-Patent
*
**/
+#include <IndustryStandard/Acpi.h>
+#include <IndustryStandard/SbsaQemuAcpi.h>
+#include <Library/AcpiLib.h>
+#include <Library/BaseMemoryLib.h>
#include <Library/DebugLib.h>
+#include <Library/MemoryAllocationLib.h>
#include <Library/PcdLib.h>
#include <Library/UefiBootServicesTableLib.h>
#include <Library/UefiDriverEntryPoint.h>
#include <Library/UefiLib.h>
+#include <Protocol/AcpiTable.h>
#include <Protocol/FdtClient.h>
#include <libfdt.h>

@@ -61,6 +67,137 @@ CountCpusFromFdt (
ASSERT_RETURN_ERROR (PcdStatus);
}

+/*
+ * A Function to Compute the ACPI Table Checksum
+ */
+VOID
+AcpiPlatformChecksum (
+ IN UINT8 *Buffer,
+ IN UINTN Size
+ )
+{
+ UINTN ChecksumOffset;
+
+ ChecksumOffset = OFFSET_OF (EFI_ACPI_DESCRIPTION_HEADER, Checksum);
+
+ // Set checksum field to 0 since it is used as part of the calculation
+ Buffer[ChecksumOffset] = 0;
+
+ Buffer[ChecksumOffset] = CalculateCheckSum8(Buffer, Size);
+}
+
+/*
+ * A function that add the MADT ACPI table.
+ IN EFI_ACPI_COMMON_HEADER *CurrentTable
+ */
+EFI_STATUS
+AddMadtTable (
+ IN EFI_ACPI_TABLE_PROTOCOL *AcpiTable
+ )
+{
+ EFI_STATUS Status;
+ UINTN TableHandle;
+ UINT32 TableSize;
+ EFI_PHYSICAL_ADDRESS PageAddress;
+ UINT8 *New;
+ UINT32 NumCores;
+
+ // Initialize MADT ACPI Header
+ EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER Header = {
+ SBSAQEMU_ACPI_HEADER (EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_SIGNATURE,
+ EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER,
+ EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_REVISION),
+ 0, 0 };
+
+ // Initialize GICC Structure
+ EFI_ACPI_6_0_GIC_STRUCTURE Gicc = EFI_ACPI_6_0_GICC_STRUCTURE_INIT (
+ 0, /* GicID */
+ 0, /* AcpiCpuUid */
+ 0, /* Mpidr */
+ EFI_ACPI_6_0_GIC_ENABLED, /* Flags */
+ SBSAQEMU_MADT_GIC_PMU_IRQ, /* PMU Irq */
+ FixedPcdGet32 (PcdGicDistributorBase), /* PhysicalBaseAddress */
+ SBSAQEMU_MADT_GIC_VBASE, /* GicVBase */
+ SBSAQEMU_MADT_GIC_HBASE, /* GicHBase */
+ 25, /* GsivId */
+ 0, /* GicRBase */
+ 0 /* Efficiency */
+ );
+
+ // Initialize GIC Distributor Structure
+ EFI_ACPI_6_0_GIC_DISTRIBUTOR_STRUCTURE Gicd =
+ EFI_ACPI_6_0_GIC_DISTRIBUTOR_INIT (
+ 0,
+ FixedPcdGet32 (PcdGicDistributorBase),
+ 0,
+ 3 /* GicVersion */
+ );
+
+ // Initialize GIC Redistributor Structure
+ EFI_ACPI_6_0_GICR_STRUCTURE Gicr = SBSAQEMU_MADT_GICR_INIT();
+
+ // Get CoreCount which was determined eariler after parsing device tree
+ NumCores = PcdGet32 (PcdCoreCount);
+
+ // Calculate the new table size based on the number of cores
+ TableSize = sizeof (EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER) +
+ (sizeof (EFI_ACPI_6_0_GIC_STRUCTURE) * NumCores) +
+ sizeof (EFI_ACPI_6_0_GIC_DISTRIBUTOR_STRUCTURE) +
+ sizeof (EFI_ACPI_6_0_GICR_STRUCTURE);
+
+ Status = gBS->AllocatePages (
+ AllocateAnyPages,
+ EfiACPIReclaimMemory,
+ EFI_SIZE_TO_PAGES (TableSize),
+ &PageAddress
+ );
+ if (EFI_ERROR(Status)) {
+ DEBUG ((DEBUG_ERROR, "Failed to allocate pages for MADT table\n"));
+ return EFI_OUT_OF_RESOURCES;
+ }
+
+ New = (UINT8 *)(UINTN) PageAddress;
+ ZeroMem (New, TableSize);
+
+ // Add the ACPI Description table header
+ CopyMem (New, &Header, sizeof (EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER));
+ ((EFI_ACPI_DESCRIPTION_HEADER*) New)->Length = TableSize;
+ New += sizeof (EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER);
+
+ // Add new GICC structures for the Cores
+ for (NumCores = 0; NumCores < PcdGet32 (PcdCoreCount); NumCores++) {
+ EFI_ACPI_6_0_GIC_STRUCTURE *GiccPtr;
+
+ CopyMem (New, &Gicc, sizeof (EFI_ACPI_6_0_GIC_STRUCTURE));
+ GiccPtr = (EFI_ACPI_6_0_GIC_STRUCTURE *) New;
+ GiccPtr->AcpiProcessorUid = NumCores;
+ GiccPtr->MPIDR = NumCores;
This does not seem to be quite correct, if I dump the MPIDRs from ARM-TF when
booting with 12 cpus this is what I get.

NOTICE: MPIDR 0
NOTICE: MPIDR 1
NOTICE: MPIDR 2
NOTICE: MPIDR 3
NOTICE: MPIDR 4
NOTICE: MPIDR 5
NOTICE: MPIDR 6
NOTICE: MPIDR 7
NOTICE: MPIDR 100
NOTICE: MPIDR 101
NOTICE: MPIDR 102
NOTICE: MPIDR 103

I think this will make PSCI operations from CPU8 onwards fail.

Thanks

Graeme


+ New += sizeof (EFI_ACPI_6_0_GIC_STRUCTURE);
+ }
+
+ // GIC Distributor Structure
+ CopyMem (New, &Gicd, sizeof (EFI_ACPI_6_0_GIC_DISTRIBUTOR_STRUCTURE));
+ New += sizeof (EFI_ACPI_6_0_GIC_DISTRIBUTOR_STRUCTURE);
+
+ // GIC ReDistributor Structure
+ CopyMem (New, &Gicr, sizeof (EFI_ACPI_6_0_GICR_STRUCTURE));
+ New += sizeof (EFI_ACPI_6_0_GICR_STRUCTURE);
+
+ AcpiPlatformChecksum ((UINT8*) PageAddress, TableSize);
+
+ Status = AcpiTable->InstallAcpiTable (
+ AcpiTable,
+ (EFI_ACPI_COMMON_HEADER *)PageAddress,
+ TableSize,
+ &TableHandle
+ );
+ if (EFI_ERROR(Status)) {
+ DEBUG ((DEBUG_ERROR, "Failed to install MADT table\n"));
+ }
+
+ return Status;
+}
+
EFI_STATUS
EFIAPI
InitializeSbsaQemuAcpiDxe (
@@ -68,8 +205,27 @@ InitializeSbsaQemuAcpiDxe (
IN EFI_SYSTEM_TABLE *SystemTable
)
{
+ EFI_STATUS Status;
+ EFI_ACPI_TABLE_PROTOCOL *AcpiTable;
+
// Parse the device tree and get the number of CPUs
CountCpusFromFdt ();

+ // Check if ACPI Table Protocol has been installed
+ Status = gBS->LocateProtocol (
+ &gEfiAcpiTableProtocolGuid,
+ NULL,
+ (VOID **)&AcpiTable
+ );
+ if (EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_ERROR, "Failed to locate ACPI Table Protocol\n"));
+ return Status;
+ }
+
+ Status = AddMadtTable (AcpiTable);
+ if (EFI_ERROR(Status)) {
+ DEBUG ((DEBUG_ERROR, "Failed to add MADT table\n"));
+ }
+
return EFI_SUCCESS;
}
--
2.28.0


Re: [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix buffer overrun in FileHandleReadLine()

Vladimir Olovyannikov
 

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Wednesday, August 26, 2020 3:03 AM
To: Vladimir Olovyannikov <vladimir.olovyannikov@...>;
devel@edk2.groups.io; zhiguang.liu@...
Cc: Kinney, Michael D <michael.d.kinney@...>; Gao, Liming
<liming.gao@...>
Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix
buffer overrun in FileHandleReadLine()

On 08/25/20 06:20, Vladimir Olovyannikov wrote:
-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Monday, August 24, 2020 9:52 AM
To: devel@edk2.groups.io; zhiguang.liu@...;
vladimir.olovyannikov@...
Cc: Kinney, Michael D <michael.d.kinney@...>; Gao, Liming
<liming.gao@...>
Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg : UefiFileHandleLib:
fix buffer overrun in FileHandleReadLine()

On 08/24/20 18:18, Laszlo Ersek wrote:
On 07/03/20 04:30, Zhiguang Liu wrote:
Reviewed-by: Zhiguang Liu <zhiguang.liu@...>
Merged as commit 4535fc312b76, via
<https://github.com/tianocore/edk2/pull/896>.
The commit message does not mention a TianoCore BZ. If there *is* an
associated TianoCore BZ, please set it to RESOLVED|FIXED now, and
also mark the above commit hash in a comment on it.

Thanks
Laszlo
Thank you Laszlo.
I modified the BZ https://bugzilla.tianocore.org/show_bug.cgi?id=2783
as you suggested.
Thanks!

In the future, if a patch is being posted for a TianoCore BZ, then please
include a line in the commit message like this:

"""
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2783
"""

Because this lets us go from git history to BZ ticket.
Sure, will do!

Thanks!
Laszlo


Re: [PATCH v7 0/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

Vladimir Olovyannikov
 

Hi Laszlo,
No worries, please let me know if you have any comments/concerns down the
road.

Thank you,
Vladimir

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Wednesday, August 26, 2020 6:56 AM
To: devel@edk2.groups.io; vladimir.olovyannikov@...
Cc: Maciej Rabeda <maciej.rabeda@...>; Zhichao Gao
<zhichao.gao@...>; Jiaxin Wu <jiaxin.wu@...>; Siyuan Fu
<siyuan.fu@...>; Ray Ni <ray.ni@...>; Liming Gao
<liming.gao@...>; Nd <nd@...>; Samer El-Haj-Mahmoud
<Samer.El-Haj-Mahmoud@...>
Subject: Re: [edk2-devel] [PATCH v7 0/1] ShellPkg/DynamicCommand: add
HttpDynamicCommand

Hi Vladimir,

On 08/25/20 19:20, Vladimir Olovyannikov via groups.io wrote:
Signed-off-by: Vladimir Olovyannikov
<vladimir.olovyannikov@...>
Reviewed-by: Maciej Rabeda <maciej.rabeda@...>
Cc: Zhichao Gao <zhichao.gao@...>
Cc: Maciej Rabeda <maciej.rabeda@...>
Cc: Jiaxin Wu <jiaxin.wu@...>
Cc: Siyuan Fu <siyuan.fu@...>
Cc: Ray Ni <ray.ni@...>
Cc: Liming Gao <liming.gao@...>
Cc: Nd <nd@...>
Cc: Laszlo Ersek <lersek@...>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>

This patchset introduces an http client utilizing EDK2 HTTP protocol,
to allow fast image downloading from http/https servers.
HTTP download speed is usually faster than tftp.
The client is based on the same approach as tftp dynamic command, and
uses the same UEFI Shell command line parameters. This makes it easy
integrating http into existing UEFI Shell scripts.
Note that to enable HTTP download, feature Pcd
gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must be set to
TRUE.

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860

PATCH v7 changes:
Address Laszlo' and Maciej's comments:
- Remove openssl submodule change accidentally added to the v6
patchset;
- Fix code style issues in the code overlooked in the previous
patchset.
I'm currently working on some VCPU hotplug fixes for the upcoming release.
Before I return to your HttpDynamicCommand patch, I'll also have to
re-read
my earlier comments for it. (In fact I can't tell off-hand if I had
remaining
requests for your patch, or not -- hence the need for re-reading my
earlier
comments.) It could take some time -- thanks for your patience.

Thanks,
Laszlo


Re: [PATCH v4 0/8] Need add a FSP binary measurement

Laszlo Ersek
 

On 08/18/20 08:26, Qi Zhang wrote:
v4 change:
rename FvEventLogRecordLib to TcgEventLogRecordLib.
v3 change:
add a new lib FvEventLogRecordLib for gerneric code.

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

The EDKII BIOS calls FSP API in FSP Wrapper Pkg.
This FSP code need to be measured into TPM.

We need add a generic module in FSP Wrapper Pkg code to measure:
1) FSP-T, FSP-M, FSP-S in API mode.
2) FSP-T in Dispatch-mode. The FSP-M and FSP-S will be reported
as standard FV and they will be measured by TCG-PEI.

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Chasel Chiu <chasel.chiu@...>
Cc: Nate DeSimone <nathaniel.l.desimone@...>
Cc: Star Zeng <star.zeng@...>
Cc: Qi Zhang <qi1.zhang@...>

Jiewen Yao (4):
IntelFsp2WrapperPkg/FspMeasurementLib: Add header file.
IntelFsp2WrapperPkg/FspMeasurementLib: Add BaseFspMeasurementLib.
IntelFsp2WraperPkg/Fsp{m|s}WrapperPeim: Add FspBin measurement.
IntelFsp2Wrapper/dsc: Add FspTpmMeasurementLib and
PcdFspMeasurementConfig.

Qi Zhang (4):
SecurityPkg/TcgEventLogRecordLib: add new lib for firmware measurement
SecurityPkg/dsc: add FvEventLogRecordLib
SecurityPkg/Tcg2: handle PRE HASH and LOG ONLY
IntelFsp2WrapperPkg/dsc: add HashLib, Tpm2CommandLib and Tpm2DeviceLib

.../FspmWrapperPeim/FspmWrapperPeim.c | 90 ++++++-
.../FspmWrapperPeim/FspmWrapperPeim.inf | 20 +-
.../FspsWrapperPeim/FspsWrapperPeim.c | 86 +++++-
.../FspsWrapperPeim/FspsWrapperPeim.inf | 27 +-
.../Include/Library/FspMeasurementLib.h | 39 +++
IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec | 17 ++
IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc | 10 +-
.../BaseFspMeasurementLib.inf | 54 ++++
.../BaseFspMeasurementLib/FspMeasurementLib.c | 248 ++++++++++++++++++
.../Include/Library/TcgEventLogRecordLib.h | 97 +++++++
SecurityPkg/Include/Ppi/Tcg.h | 5 +
.../TcgEventLogRecordLib.c | 197 ++++++++++++++
.../TcgEventLogRecordLib.inf | 40 +++
.../TcgEventLogRecordLib.uni | 17 ++
SecurityPkg/SecurityPkg.dec | 3 +
SecurityPkg/SecurityPkg.dsc | 2 +
SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c | 12 +-
17 files changed, 939 insertions(+), 25 deletions(-)
create mode 100644 IntelFsp2WrapperPkg/Include/Library/FspMeasurementLib.h
create mode 100644 IntelFsp2WrapperPkg/Library/BaseFspMeasurementLib/BaseFspMeasurementLib.inf
create mode 100644 IntelFsp2WrapperPkg/Library/BaseFspMeasurementLib/FspMeasurementLib.c
create mode 100644 SecurityPkg/Include/Library/TcgEventLogRecordLib.h
create mode 100644 SecurityPkg/Library/TcgEventLogRecordLib/TcgEventLogRecordLib.c
create mode 100644 SecurityPkg/Library/TcgEventLogRecordLib/TcgEventLogRecordLib.inf
create mode 100644 SecurityPkg/Library/TcgEventLogRecordLib/TcgEventLogRecordLib.uni
Merged as commit range 78ab44cb9680..63d92674d240, via
<https://github.com/tianocore/edk2/pull/904>, with the v3 feedback tags
brought forward, as explained here:
<https://edk2.groups.io/g/devel/message/64642>.

Thanks
Laszlo


Re: Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

Yao, Jiewen
 

Thank you very much, Laszlo and Liming!

Thank you
Yao Jiewen

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Wednesday, August 26, 2020 10:49 PM
To: Yao, Jiewen <jiewen.yao@...>; devel@edk2.groups.io; gaoliming
<gaoliming@...>; 'Leif Lindholm' <leif@...>;
afish@...; Kinney, Michael D <michael.d.kinney@...>; Guptha,
Soumya K <soumya.k.guptha@...>
Cc: announce@edk2.groups.io; 'Chang, Abner (HPS SW/FW Technologist)'
<abner.chang@...>; Zhang, Qi1 <qi1.zhang@...>;
marcello.bauer@...
Subject: Re: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for
edk2-stable202008

On 08/26/20 12:16, Yao, Jiewen wrote:
HI Laszlo
I checked the history.

Jiewen replied " [PATCH v3 0/8] Need add a FSP binary measurement" with
review-by on V3 patch series in August 15, with comment to rename
FvEventLogRecordLib to TcgEventLogRecordLib.

You are correct:

https://edk2.groups.io/g/devel/message/64299

I have two comments on this.

First, because you authored the IntelFsp2WrapperPkg patches in the
series, you cannot R-b them (you cannot R-b your own patches, even if
they are resent by someone else). However, that's not necessary: the
IntelFsp2WrapperPkg is maintained by Chasel Chiu, and Chasel did review
those patches, under v4, in the end.

Second, the v4 submitter, Qi Zhang, should have picked up your R-b from
under v3, and included them in the v4 posting. (Assuming the v3->v4
changes were exactly as you requested, under v3.)

Qi sent v4 series in August 17, with only naming change from
FvEventLogRecordLib to TcgEventLogRecordLib.

OK. In this case, Qi should have posted the v4 SecurityPkg patches with
your R-b *already* present.

Jian replied "[PATCH v3 0/8] Need add a FSP binary measurement" with
reviewed-by on V3 patch series in August 18.

That's correct too:

https://edk2.groups.io/g/devel/message/64342

This means that Qi should have sent v4 with Jian's R-b on *every* patch.

So I treat this patch series is qualified to check in (since V4 adopted my
comment). But please let me know if there is any misunderstanding.

No, you are entirely correct. I was misled because v4 was not posted
correctly, with regard to the feedback tags given under v3.

So, what remains to do now is this: until the HFF (2020-08-28) we can,
and should, merge v4 of the series. As follows:

- apply Jian's R-b from under v3 to every patch in the series

- apply your R-b from under v3 to the patches you did *not* author (that
is, apply the tag to the SecurityPkg patches, plus to
"IntelFsp2WrapperPkg/dsc: add HashLib, Tpm2CommandLib and
Tpm2DeviceLib")

- apply Chasel Chiu's R-b from under v4 to the IntelFsp2WrapperPkg patches.

This will make the series fully reviewed, and mergeable.

Note that Chasel requested a copyright year update when pushing, here:
<https://edk2.groups.io/g/devel/message/64382>. Given that Chasel
(maintainer/reviewer), Jiewen (original author) and Qi (poster) all work
for Intel, and the (C) notice in question is Intel's, I think that *any*
maintainer can satisfy Chasel's request, when merging the series.

So, I think I'll go ahead and merge v4. Thank you for the v3 pointers.

When I am about to merge, I am told that we are in SFF and I cannot check in.
According to the plan, I will check in after August 28, which is end of August. It
is still OK for me.
2020-08-14 Soft Feature Freeze
2020-08-21 Hard Feature Freeze
2020-08-28 Release

But now, if we need delay one week, then the final release data will be
September. If I cannot check in now, I will have to check in at September.
That is why I said, it impacts me, because of this one week delay.
I'm going to merge the series for you, given the amount of work needed
for collecting the feedback tags.

Thanks!
Laszlo


Re: Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

Laszlo Ersek
 

On 08/26/20 12:16, Yao, Jiewen wrote:
HI Laszlo
I checked the history.

Jiewen replied " [PATCH v3 0/8] Need add a FSP binary measurement" with review-by on V3 patch series in August 15, with comment to rename FvEventLogRecordLib to TcgEventLogRecordLib.
You are correct:

https://edk2.groups.io/g/devel/message/64299

I have two comments on this.

First, because you authored the IntelFsp2WrapperPkg patches in the
series, you cannot R-b them (you cannot R-b your own patches, even if
they are resent by someone else). However, that's not necessary: the
IntelFsp2WrapperPkg is maintained by Chasel Chiu, and Chasel did review
those patches, under v4, in the end.

Second, the v4 submitter, Qi Zhang, should have picked up your R-b from
under v3, and included them in the v4 posting. (Assuming the v3->v4
changes were exactly as you requested, under v3.)

Qi sent v4 series in August 17, with only naming change from FvEventLogRecordLib to TcgEventLogRecordLib.
OK. In this case, Qi should have posted the v4 SecurityPkg patches with
your R-b *already* present.

Jian replied "[PATCH v3 0/8] Need add a FSP binary measurement" with reviewed-by on V3 patch series in August 18.
That's correct too:

https://edk2.groups.io/g/devel/message/64342

This means that Qi should have sent v4 with Jian's R-b on *every* patch.

So I treat this patch series is qualified to check in (since V4 adopted my comment). But please let me know if there is any misunderstanding.
No, you are entirely correct. I was misled because v4 was not posted
correctly, with regard to the feedback tags given under v3.

So, what remains to do now is this: until the HFF (2020-08-28) we can,
and should, merge v4 of the series. As follows:

- apply Jian's R-b from under v3 to every patch in the series

- apply your R-b from under v3 to the patches you did *not* author (that
is, apply the tag to the SecurityPkg patches, plus to
"IntelFsp2WrapperPkg/dsc: add HashLib, Tpm2CommandLib and Tpm2DeviceLib")

- apply Chasel Chiu's R-b from under v4 to the IntelFsp2WrapperPkg patches.

This will make the series fully reviewed, and mergeable.

Note that Chasel requested a copyright year update when pushing, here:
<https://edk2.groups.io/g/devel/message/64382>. Given that Chasel
(maintainer/reviewer), Jiewen (original author) and Qi (poster) all work
for Intel, and the (C) notice in question is Intel's, I think that *any*
maintainer can satisfy Chasel's request, when merging the series.

So, I think I'll go ahead and merge v4. Thank you for the v3 pointers.

When I am about to merge, I am told that we are in SFF and I cannot check in.
According to the plan, I will check in after August 28, which is end of August. It is still OK for me.
2020-08-14 Soft Feature Freeze
2020-08-21 Hard Feature Freeze
2020-08-28 Release

But now, if we need delay one week, then the final release data will be September. If I cannot check in now, I will have to check in at September.
That is why I said, it impacts me, because of this one week delay.
I'm going to merge the series for you, given the amount of work needed
for collecting the feedback tags.

Thanks!
Laszlo


Re: [PATCH v7 0/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

Laszlo Ersek
 

Hi Vladimir,

On 08/25/20 19:20, Vladimir Olovyannikov via groups.io wrote:
Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@...>
Reviewed-by: Maciej Rabeda <maciej.rabeda@...>
Cc: Zhichao Gao <zhichao.gao@...>
Cc: Maciej Rabeda <maciej.rabeda@...>
Cc: Jiaxin Wu <jiaxin.wu@...>
Cc: Siyuan Fu <siyuan.fu@...>
Cc: Ray Ni <ray.ni@...>
Cc: Liming Gao <liming.gao@...>
Cc: Nd <nd@...>
Cc: Laszlo Ersek <lersek@...>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>

This patchset introduces an http client utilizing EDK2 HTTP protocol, to
allow fast image downloading from http/https servers.
HTTP download speed is usually faster than tftp.
The client is based on the same approach as tftp dynamic command, and
uses the same UEFI Shell command line parameters. This makes it easy
integrating http into existing UEFI Shell scripts.
Note that to enable HTTP download, feature Pcd
gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must be set to TRUE.

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860

PATCH v7 changes:
Address Laszlo' and Maciej's comments:
- Remove openssl submodule change accidentally added to the v6 patchset;
- Fix code style issues in the code overlooked in the previous patchset.
I'm currently working on some VCPU hotplug fixes for the upcoming
release. Before I return to your HttpDynamicCommand patch, I'll also
have to re-read my earlier comments for it. (In fact I can't tell
off-hand if I had remaining requests for your patch, or not -- hence the
need for re-reading my earlier comments.) It could take some time --
thanks for your patience.

Thanks,
Laszlo


回复: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

gaoliming
 

Jiewen:

For this patch set V3, I see you give reviewed-by on Aug 15th https://edk2.groups.io/g/devel/message/64299
For V4, https://edk2.groups.io/g/devel/message/64354, it makes the change per your comment.
So, I agree you as SecurityPkg maintainter reviewed-by is OK for V4 patch set.

And, I also see Chiu, Chasel as IntelFsp2WrapperPkg maintainer gives reviewed-by on Aug 18th for the changes in IntelFsp2WrapperPkg

So, I think the latest patch set V4 finished code review before new SFF start date (2020-08-24).
Based on SFF definition, I agree this patch set can be merged for this stable tag 202008.

Thanks
Liming

-----邮件原件-----
发件人: bounce+27952+64638+4905953+8761045@groups.io
<bounce+27952+64638+4905953+8761045@groups.io> 代表 Yao, Jiewen
发送时间: 2020年8月26日 18:17
收件人: Laszlo Ersek <lersek@...>; devel@edk2.groups.io; gaoliming
<gaoliming@...>; 'Leif Lindholm' <leif@...>;
afish@...; Kinney, Michael D <michael.d.kinney@...>; Guptha,
Soumya K <soumya.k.guptha@...>
抄送: announce@edk2.groups.io; 'Chang, Abner (HPS SW/FW Technologist)'
<abner.chang@...>; Zhang, Qi1 <qi1.zhang@...>;
marcello.bauer@...
主题: Re: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for
edk2-stable202008

HI Laszlo
I checked the history.

Jiewen replied " [PATCH v3 0/8] Need add a FSP binary measurement" with
review-by on V3 patch series in August 15, with comment to rename
FvEventLogRecordLib to TcgEventLogRecordLib.
Qi sent v4 series in August 17, with only naming change from
FvEventLogRecordLib to TcgEventLogRecordLib.
Jian replied "[PATCH v3 0/8] Need add a FSP binary measurement" with
reviewed-by on V3 patch series in August 18.

So I treat this patch series is qualified to check in (since V4 adopted my
comment). But please let me know if there is any misunderstanding.


When I am about to merge, I am told that we are in SFF and I cannot check in.
According to the plan, I will check in after August 28, which is end of August. It
is still OK for me.
2020-08-14 Soft Feature Freeze
2020-08-21 Hard Feature Freeze
2020-08-28 Release

But now, if we need delay one week, then the final release data will be
September. If I cannot check in now, I will have to check in at September.
That is why I said, it impacts me, because of this one week delay.

Thank you
Yao Jiewen


-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Wednesday, August 26, 2020 5:54 PM
To: Yao, Jiewen <jiewen.yao@...>; devel@edk2.groups.io; gaoliming
<gaoliming@...>; 'Leif Lindholm' <leif@...>;
afish@...; Kinney, Michael D <michael.d.kinney@...>;
Guptha,
Soumya K <soumya.k.guptha@...>
Cc: announce@edk2.groups.io; 'Chang, Abner (HPS SW/FW Technologist)'
<abner.chang@...>; Zhang, Qi1 <qi1.zhang@...>;
marcello.bauer@...
Subject: Re: [edk2-devel] Soft Feature Freeze start date delays to
2020-08-24 for
edk2-stable202008

Hi Jiewen,

On 08/26/20 03:19, Yao, Jiewen wrote:
To clarify below:
I just notice this one week delay. It impacts us.

https://edk2.groups.io/g/devel/message/64354
[PATCH v4 0/8] Need add a FSP binary measurement
The SecurityPkg patches have not been approved yet, and Bret and
Jiewen are still testing / discussing (as far as I understand):
<https://edk2.groups.io/g/devel/message/64526>. Material for the next
tag.

[Jiewen] I think the security pkg is already approved by me and Jian
(SecurityPkg maintainer) Bret also provides feedback that it looks
good.
The series in question has three SecurityPkg patches:

[PATCH v4 1/8] SecurityPkg/TcgEventLogRecordLib: add new lib for
firmware
measurement
[PATCH v4 5/8] SecurityPkg/dsc: add FvEventLogRecordLib
[PATCH v4 7/8] SecurityPkg/Tcg2: handle PRE HASH and LOG ONLY

As I'm writing this, *none* of the listed patches have any kind of
Reviewed-by or Acked-by, either included in the patches themselves, or
posted in response to them.

I request to check in to stable202008, if possible.
We can do that only if (a) we extend the SFF deadline again, and (b)
each of the SecurityPkg patches receives at least an Acked-by from one
of the SecurityPkg maintainers, until the new deadline.

I'm certainly not against the idea. I don't mind if the release slips
some more; it's OK to say that we're not ready to release yet. The point
is, as long as we're doing more work for completing the release, we
should prolong the stabilization period as well (opportunity for people
to test).

Thanks,
Laszlo


Re: question about EDKII_IOMMU_PROTOCOL

Laszlo Ersek
 

On 08/25/20 09:39, Tiger Liu(BJ-RD) wrote:
Hi, Experts:
I find EDKII_IOMMU_PROTOCOL definition in MdeModulePkg\Include\Protocol\IoMmu.h .

But I didn't find its define in UEFI Spec or PI Spec.
So, is it a private protocol definition?
Yes -- that's why the protocol name starts with the "EDKII_" prefix, and
why the header file is under MdeModulePkg and not MdePkg.

It's an "implementation detail" in edk2.

Thanks,
Laszlo


Re: Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

Yao, Jiewen
 

HI Laszlo
I checked the history.

Jiewen replied " [PATCH v3 0/8] Need add a FSP binary measurement" with review-by on V3 patch series in August 15, with comment to rename FvEventLogRecordLib to TcgEventLogRecordLib.
Qi sent v4 series in August 17, with only naming change from FvEventLogRecordLib to TcgEventLogRecordLib.
Jian replied "[PATCH v3 0/8] Need add a FSP binary measurement" with reviewed-by on V3 patch series in August 18.

So I treat this patch series is qualified to check in (since V4 adopted my comment). But please let me know if there is any misunderstanding.


When I am about to merge, I am told that we are in SFF and I cannot check in.
According to the plan, I will check in after August 28, which is end of August. It is still OK for me.
2020-08-14 Soft Feature Freeze
2020-08-21 Hard Feature Freeze
2020-08-28 Release

But now, if we need delay one week, then the final release data will be September. If I cannot check in now, I will have to check in at September.
That is why I said, it impacts me, because of this one week delay.

Thank you
Yao Jiewen

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Wednesday, August 26, 2020 5:54 PM
To: Yao, Jiewen <jiewen.yao@...>; devel@edk2.groups.io; gaoliming
<gaoliming@...>; 'Leif Lindholm' <leif@...>;
afish@...; Kinney, Michael D <michael.d.kinney@...>; Guptha,
Soumya K <soumya.k.guptha@...>
Cc: announce@edk2.groups.io; 'Chang, Abner (HPS SW/FW Technologist)'
<abner.chang@...>; Zhang, Qi1 <qi1.zhang@...>;
marcello.bauer@...
Subject: Re: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for
edk2-stable202008

Hi Jiewen,

On 08/26/20 03:19, Yao, Jiewen wrote:
To clarify below:
I just notice this one week delay. It impacts us.

https://edk2.groups.io/g/devel/message/64354
[PATCH v4 0/8] Need add a FSP binary measurement
The SecurityPkg patches have not been approved yet, and Bret and
Jiewen are still testing / discussing (as far as I understand):
<https://edk2.groups.io/g/devel/message/64526>. Material for the next
tag.

[Jiewen] I think the security pkg is already approved by me and Jian
(SecurityPkg maintainer) Bret also provides feedback that it looks
good.
The series in question has three SecurityPkg patches:

[PATCH v4 1/8] SecurityPkg/TcgEventLogRecordLib: add new lib for firmware
measurement
[PATCH v4 5/8] SecurityPkg/dsc: add FvEventLogRecordLib
[PATCH v4 7/8] SecurityPkg/Tcg2: handle PRE HASH and LOG ONLY

As I'm writing this, *none* of the listed patches have any kind of
Reviewed-by or Acked-by, either included in the patches themselves, or
posted in response to them.

I request to check in to stable202008, if possible.
We can do that only if (a) we extend the SFF deadline again, and (b)
each of the SecurityPkg patches receives at least an Acked-by from one
of the SecurityPkg maintainers, until the new deadline.

I'm certainly not against the idea. I don't mind if the release slips
some more; it's OK to say that we're not ready to release yet. The point
is, as long as we're doing more work for completing the release, we
should prolong the stabilization period as well (opportunity for people
to test).

Thanks,
Laszlo


Re: [PATCH v2 2/2] CryptoPkg/OpensslLib: Commit the auto-generated assembly files for X64

Laszlo Ersek
 

On 08/25/20 02:55, Andrew Fish wrote:


On Aug 19, 2020, at 11:06 AM, Laszlo Ersek <lersek@...> wrote:

On 08/19/20 17:37, Andrew Fish via groups.io wrote:


On Aug 18, 2020, at 2:22 PM, Zurcher, Christopher J <christopher.j.zurcher@...> wrote:

Per the added header comment in process_files.pl:

# Due to the script wrapping required to process the OpenSSL
# configuration data, each native architecture must be processed
# individually by the maintainer (in addition to the standard version):
# ./process_files.pl
Side note: process_file.pl is missing a copyright statement.
True :(

Andrew, could you please report a BZ about it?
https://bugzilla.tianocore.org/show_bug.cgi?id=2925
Thanks much!
Laszlo


Re: [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix buffer overrun in FileHandleReadLine()

Laszlo Ersek
 

On 08/25/20 06:20, Vladimir Olovyannikov wrote:
-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Monday, August 24, 2020 9:52 AM
To: devel@edk2.groups.io; zhiguang.liu@...;
vladimir.olovyannikov@...
Cc: Kinney, Michael D <michael.d.kinney@...>; Gao, Liming
<liming.gao@...>
Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix
buffer overrun in FileHandleReadLine()

On 08/24/20 18:18, Laszlo Ersek wrote:
On 07/03/20 04:30, Zhiguang Liu wrote:
Reviewed-by: Zhiguang Liu <zhiguang.liu@...>
Merged as commit 4535fc312b76, via
<https://github.com/tianocore/edk2/pull/896>.
The commit message does not mention a TianoCore BZ. If there *is* an
associated TianoCore BZ, please set it to RESOLVED|FIXED now, and also
mark the above commit hash in a comment on it.

Thanks
Laszlo
Thank you Laszlo.
I modified the BZ https://bugzilla.tianocore.org/show_bug.cgi?id=2783 as you
suggested.
Thanks!

In the future, if a patch is being posted for a TianoCore BZ, then
please include a line in the commit message like this:

"""
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2783
"""

Because this lets us go from git history to BZ ticket.

Thanks!
Laszlo


Re: Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

Laszlo Ersek
 

Hi Jiewen,

On 08/26/20 03:19, Yao, Jiewen wrote:
To clarify below:
I just notice this one week delay. It impacts us.

https://edk2.groups.io/g/devel/message/64354
[PATCH v4 0/8] Need add a FSP binary measurement
The SecurityPkg patches have not been approved yet, and Bret and
Jiewen are still testing / discussing (as far as I understand):
<https://edk2.groups.io/g/devel/message/64526>. Material for the next
tag.

[Jiewen] I think the security pkg is already approved by me and Jian
(SecurityPkg maintainer) Bret also provides feedback that it looks
good.
The series in question has three SecurityPkg patches:

[PATCH v4 1/8] SecurityPkg/TcgEventLogRecordLib: add new lib for firmware measurement
[PATCH v4 5/8] SecurityPkg/dsc: add FvEventLogRecordLib
[PATCH v4 7/8] SecurityPkg/Tcg2: handle PRE HASH and LOG ONLY

As I'm writing this, *none* of the listed patches have any kind of
Reviewed-by or Acked-by, either included in the patches themselves, or
posted in response to them.

I request to check in to stable202008, if possible.
We can do that only if (a) we extend the SFF deadline again, and (b)
each of the SecurityPkg patches receives at least an Acked-by from one
of the SecurityPkg maintainers, until the new deadline.

I'm certainly not against the idea. I don't mind if the release slips
some more; it's OK to say that we're not ready to release yet. The point
is, as long as we're doing more work for completing the release, we
should prolong the stabilization period as well (opportunity for people
to test).

Thanks,
Laszlo


Re: [PATCH v6 00/14] Add the VariablePolicy feature

Bret Barkelew <bret.barkelew@...>
 

Dandan,

 

I’ve addressed points 1-3 in this commit:

https://github.com/corthon/edk2/tree/var_policy_dev_submission_v7

 

I’ve also added a note to the new ReadMe about point #6:

https://github.com/corthon/edk2/tree/var_policy_dev_submission_v7/MdeModulePkg/Library/VariablePolicyLib#disablevariablepolicy

 

Will put up a v7 of patches this week.

 

- Bret

 

From: Bret Barkelew via groups.io
Sent: Monday, August 17, 2020 10:24 PM
To: devel@edk2.groups.io; dandan.bi@...; bret@...
Cc: Yao, Jiewen; Zhang, Chao B; Wang, Jian J; Wu, Hao A; liming.gao; Justen, Jordan L; Laszlo Ersek; Ard Biesheuvel; Andrew Fish; Ni, Ray
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v6 00/14] Add the VariablePolicy feature

 

Responses below…

 

- Bret

 

From: Dandan Bi via groups.io
Sent: Tuesday, August 11, 2020 6:52 AM
To: devel@edk2.groups.io; Bi, Dandan; bret@...
Cc: Yao, Jiewen; Zhang, Chao B; Wang, Jian J; Wu, Hao A; liming.gao; Justen, Jordan L; Laszlo Ersek; Ard Biesheuvel; Andrew Fish; Ni, Ray
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v6 00/14] Add the VariablePolicy feature

 

Hi Bret,

Sorry for the delayed response.

Some more comments here:

1. Currently I see the LockVaribePolicy is called at ReadyToBoot by variable driver, could we update it to be called at EndOfDxe? We should prevent malicious code registering policy after EndOfDxe for security concern. And could we also add the test case to check the variable policy is locked at EndofDxe?

We could. Right now it’s at ReadyToBoot because it’s just there as a safety net and the platform could lock it earlier. Would it work to have a PCD for which EventGroup GUID the platform should lock on?

2. For patch 4, the SMM communication,  some general guidelines for SMI handler:
a)  Check whether the communication buffer is outside SMM and valid.
For this feature, please double check whether the communication buffer is checked, if all the range in communication buffer has already been checked within existing edk2 core infrastructure, please also add the comments in the code to mention that it has been checked.

I checked this, but I will recheck (since there’ve been a few revisions in the patches) and update the comments.

b) Should copy the communication buffer to SMRAM before checking the data fields to avoid TOC/TOU attac
For this feature, for example, when dump variable policy, if malicious code updates the DumpParams->TotalSize in communication buffer to smaller one to allocate the PaginationCache buffer, and then update it the correct one and dump the variable policy data into the PaginationCache buffer, it will cause buffer overflow in this case.  So please double check the code and copy the communication buffer into SMRAM to avoid such kind issue.

Will also check for this.

3. Did you do any security test for this feature?

Such as? There are both unit tests and integration tests to ensure correct functionality and that the disable and lock interfaces work as expected. I haven’t fuzzed it or anything that involved.

4. Currently, LockVariablePolicy can prevent RegisterVariablePolicy and DisableVariablePolicy. So in SMI hander, could we check the variable policy is locked or not firstly and then decide whether need to check and execution for VAR_CHECK_POLICY_COMMAND_REGISTER and VAR_CHECK_POLICY_COMMAND_DISABLE?

I’ll take a look, but my gut says this may be an unnecessary complication.

5. Since there is the logic when variable policy is disabled, it will permit deletion of auth/protected variables. Could we add some comments in code to mention that variable policy should always be enabled for security concern to avoid giving bad example?

I’m happy to think about how to document this, but I’m not immediately inclined to outright say it shouldn’t be disabled. I’d be happy to say that it shouldn’t be disabled in “normal, production configuration”, but it’s entirely reasonable to be disabled in a Manufacturing or R&R environment and we would actually prefer this be used because it would at least be consistent across platforms, rather than being something done ad hoc by each platform that needs it. Would that be sufficient?

Thanks,
Dandan

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Dandan
> Bi
> Sent: Thursday, July 2, 2020 10:14 AM
> To: devel@edk2.groups.io; bret@...
> Cc: Yao, Jiewen <jiewen.yao@...>; Zhang, Chao B
> <chao.b.zhang@...>; Wang, Jian J <jian.j.wang@...>; Wu, Hao
> A <hao.a.wu@...>; Gao, Liming <liming.gao@...>; Justen,
> Jordan L <jordan.l.justen@...>; Laszlo Ersek <lersek@...>;
> Ard Biesheuvel <ard.biesheuvel@...>; Andrew Fish
> <afish@...>; Ni, Ray <ray.ni@...>
> Subject: Re: [edk2-devel] [PATCH v6 00/14] Add the VariablePolicy feature
>
> Hi Bret,
>
> Thanks for the contribution.
>
> I have taken an overview of this patch series and have some small comments
> in the related patches, please check in sub-patch.
>
> I will review the patch series more in details and bring more comments back
> if have. Do you have a branch for these patches in GitHub? Which should be
> easy for review.
>
>
> Thanks,
> Dandan
>
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Bret
> > Barkelew
> > Sent: Tuesday, June 23, 2020 2:41 PM
> > To: devel@edk2.groups.io
> > Cc: Yao, Jiewen <jiewen.yao@...>; Zhang, Chao B
> > <chao.b.zhang@...>; Wang, Jian J <jian.j.wang@...>; Wu,
> > Hao A <hao.a.wu@...>; Gao, Liming <liming.gao@...>;
> > Justen, Jordan L <jordan.l.justen@...>; Laszlo Ersek
> > <lersek@...>; Ard Biesheuvel <ard.biesheuvel@...>;
> Andrew
> > Fish <afish@...>; Ni, Ray <ray.ni@...>
> > Subject: [edk2-devel] [PATCH v6 00/14] Add the VariablePolicy feature
> >
> > REF:https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2522&amp;data=02%7C01%7CBret.Barkelew%40microsoft.com%7C91eed7c4a0d54e2eff6008d83dfdc4ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637327507431539442&amp;sdata=cLpx7VZsG%2F6r6GCXmiCS4DmmgOH4iKfX3VSAAYUOU00%3D&amp;reserved=0
> >
> > The 14 patches in this series add the VariablePolicy feature to the
> > core, deprecate Edk2VarLock (while adding a compatibility layer to
> > reduce code churn), and integrate the VariablePolicy libraries and
> > protocols into Variable Services.
> >
> > Since the integration requires multiple changes, including adding
> > libraries, a protocol, an SMI communication handler, and
> > VariableServices integration, the patches are broken up by individual
> > library additions and then a final integration. Security-sensitive
> > changes like bypassing Authenticated Variable enforcement are also
> > broken out into individual patches so that attention can be called directly to
> them.
> >
> > Platform porting instructions are described in this wiki entry:
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FVariablePolicy-&amp;data=02%7C01%7CBret.Barkelew%40microsoft.com%7C91eed7c4a0d54e2eff6008d83dfdc4ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637327507431539442&amp;sdata=%2FYNgK7yixA5Gi7E9bHw3LIUNAQpZMh9ykTUqCqv2SRY%3D&amp;reserved=0
> > Protocol---Enhanced-Method-for-Managing-Variables#platform-porting
> >
> > Discussion of the feature can be found in multiple places throughout
> > the last year on the RFC channel, staging branches, and in devel.
> >
> > Most recently, this subject was discussed in this thread:
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F53712&amp;data=02%7C01%7CBret.Barkelew%40microsoft.com%7C91eed7c4a0d54e2eff6008d83dfdc4ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637327507431539442&amp;sdata=i7qaO6eZT8%2BzCT0satTptMWwCNspDz%2BS05eJmGGR628%3D&amp;reserved=0
> > (the code branches shared in that discussion are now out of date, but
> > the whitepapers and discussion are relevant).
> >
> > Cc: Jiewen Yao <jiewen.yao@...>
> > Cc: Chao Zhang <chao.b.zhang@...>
> > Cc: Jian J Wang <jian.j.wang@...>
> > Cc: Hao A Wu <hao.a.wu@...>
> > Cc: Liming Gao <liming.gao@...>
> > Cc: Jordan Justen <jordan.l.justen@...>
> > Cc: Laszlo Ersek <lersek@...>
> > Cc: Ard Biesheuvel <ard.biesheuvel@...>
> > Cc: Andrew Fish <afish@...>
> > Cc: Ray Ni <ray.ni@...>
> > Cc: Bret Barkelew <brbarkel@...>
> > Signed-off-by: Bret Barkelew <brbarkel@...>
> >
> > v6 changes:
> > * Fix an issue with uninitialized Status in InitVariablePolicyLib()
> > and
> > DeinitVariablePolicyLib()
> > * Fix GCC building in shell-based functional test
> > * Rebase on latest origin/master
> >
> > v5 changes:
> > * Fix the CONST mismatch in VariablePolicy.h and
> > VariablePolicySmmDxe.c
> > * Fix EFIAPI mismatches in the functional unittest
> > * Rebase on latest origin/master
> >
> > v4 changes:
> > * Remove Optional PcdAllowVariablePolicyEnforcementDisable PCD from
> > platforms
> > * Rebase on master
> > * Migrate to new MmCommunicate2 protocol
> > * Fix an oversight in the default return value for
> > InitMmCommonCommBuffer
> > * Fix in VariablePolicyLib to allow ExtraInitRuntimeDxe to consume
> > variables
> >
> > V3 changes:
> > * Address all non-unittest issues with ECC
> > * Make additional style changes
> > * Include section name in hunk headers in "ini-style" files
> > * Remove requirement for the EdkiiPiSmmCommunicationsRegionTable
> > driver
> >   (now allocates its own buffer)
> > * Change names from VARIABLE_POLICY_PROTOCOL and
> > gVariablePolicyProtocolGuid
> >   to EDKII_VARIABLE_POLICY_PROTOCOL and
> > gEdkiiVariablePolicyProtocolGuid
> > * Fix GCC warning about initializing externs
> > * Add UNI strings for new PCD
> > * Add patches for ArmVirtPkg, OvmfXen, and UefiPayloadPkg
> > * Reorder patches according to Liming's feedback about adding to
> platforms
> >   before changing variable driver
> >
> > V2 changes:
> > * Fixed implementation for RuntimeDxe
> > * Add PCD to block DisableVariablePolicy
> > * Fix the DumpVariablePolicy pagination in SMM
> >
> > Bret Barkelew (14):
> >   MdeModulePkg: Define the VariablePolicy protocol interface
> >   MdeModulePkg: Define the VariablePolicyLib
> >   MdeModulePkg: Define the VariablePolicyHelperLib
> >   MdeModulePkg: Define the VarCheckPolicyLib and SMM interface
> >   OvmfPkg: Add VariablePolicy engine to OvmfPkg platform
> >   EmulatorPkg: Add VariablePolicy engine to EmulatorPkg platform
> >   ArmVirtPkg: Add VariablePolicy engine to ArmVirtPkg platform
> >   UefiPayloadPkg: Add VariablePolicy engine to UefiPayloadPkg platform
> >   MdeModulePkg: Connect VariablePolicy business logic to
> >     VariableServices
> >   MdeModulePkg: Allow VariablePolicy state to delete protected variables
> >   SecurityPkg: Allow VariablePolicy state to delete authenticated
> >     variables
> >   MdeModulePkg: Change TCG MOR variables to use VariablePolicy
> >   MdeModulePkg: Drop VarLock from RuntimeDxe variable driver
> >   MdeModulePkg: Add a shell-based functional test for VariablePolicy
> >
> >  MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
> > |  320 +++
> >
> > MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.c
> > |  396 ++++
> >  MdeModulePkg/Library/VariablePolicyLib/VariablePolicyExtraInitNull.c
> > |   46 +
> >
> >
> MdeModulePkg/Library/VariablePolicyLib/VariablePolicyExtraInitRuntimeDx
> > e.c               |   85 +
> >  MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.c
> > |  816 +++++++
> >
> >
> MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/VariablePo
> > licyUnitTest.c   | 2440 ++++++++++++++++++++
> >
> >
> MdeModulePkg/Test/ShellTest/VariablePolicyFuncTestApp/VariablePolicyFu
> > ncTestApp.c        | 1978 ++++++++++++++++
> >  MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
> > |   52 +-
> >  MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> > |   60 +-
> >  MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c
> > |   49 +-
> >  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> > |   53 +
> >
> >
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableLockRequstToLock
> > .c                    |   71 +
> >  MdeModulePkg/Universal/Variable/RuntimeDxe/VariablePolicySmmDxe.c
> > |  642 +++++
> >
> >
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.
> > c                       |   14 +
> >  SecurityPkg/Library/AuthVariableLib/AuthService.c                                        |
> 22
> > +-
> >  ArmVirtPkg/ArmVirt.dsc.inc                                                               |    4 +
> >  EmulatorPkg/EmulatorPkg.dsc                                                              |    3 +
> >  MdeModulePkg/Include/Guid/VarCheckPolicyMmi.h
> |
> > 54 +
> >  MdeModulePkg/Include/Library/VariablePolicyHelperLib.h
> > |  164 ++
> >  MdeModulePkg/Include/Library/VariablePolicyLib.h                                         |
> > 207 ++
> >  MdeModulePkg/Include/Protocol/VariablePolicy.h                                           |
> > 157 ++
> >  MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.inf
> > |   42 +
> >  MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.uni
> > |   12 +
> >
> > MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.i
> > nf
> > |   35 +
> >
> > MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.u
> > ni
> > |   12 +
> >  MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf
> > |   44 +
> >  MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.uni
> > |   12 +
> >
> > MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf
> > |   51 +
> >
> >
> MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/VariablePo
> > licyUnitTest.inf |   40 +
> >  MdeModulePkg/MdeModulePkg.ci.yaml                                                        |    4
> +-
> >  MdeModulePkg/MdeModulePkg.dec                                                            |   26 +-
> >  MdeModulePkg/MdeModulePkg.dsc                                                            |   15 +
> >  MdeModulePkg/MdeModulePkg.uni                                                            |    7 +
> >  MdeModulePkg/Test/MdeModulePkgHostTest.dsc
> |
> > 11 +
> >  MdeModulePkg/Test/ShellTest/VariablePolicyFuncTestApp/Readme.md
> > |   55 +
> >
> >
> MdeModulePkg/Test/ShellTest/VariablePolicyFuncTestApp/VariablePolicyFu
> > ncTestApp.inf      |   42 +
> >  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
> > |    5 +
> >  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> > |    4 +
> >
> >
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.i
> > nf                     |   10 +
> >
> >
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> > |    4 +
> >  OvmfPkg/OvmfPkgIa32.dsc                                                                  |    5 +
> >  OvmfPkg/OvmfPkgIa32X64.dsc                                                               |    5 +
> >  OvmfPkg/OvmfPkgX64.dsc                                                                   |    5 +
> >  OvmfPkg/OvmfXen.dsc                                                                      |    4 +
> >  SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf                                  |
> > 2 +
> >  UefiPayloadPkg/UefiPayloadPkgIa32.dsc                                                    |    4 +
> >  UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc                                                 |    4 +
> >  47 files changed, 8015 insertions(+), 78 deletions(-)  create mode
> > 100644 MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
> >  create mode 100644
> > MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.c
> >  create mode 100644
> > MdeModulePkg/Library/VariablePolicyLib/VariablePolicyExtraInitNull.c
> >  create mode 100644
> > MdeModulePkg/Library/VariablePolicyLib/VariablePolicyExtraInitRuntimeD
> > x
> > e.c
> >  create mode 100644
> > MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.c
> >  create mode 100644
> > MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/Variable
> > Po
> > licyUnitTest.c
> >  create mode 100644
> >
> MdeModulePkg/Test/ShellTest/VariablePolicyFuncTestApp/VariablePolicyFu
> > ncTestApp.c
> >  create mode 100644
> >
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableLockRequstToLock
> > .c
> >  create mode 100644
> > MdeModulePkg/Universal/Variable/RuntimeDxe/VariablePolicySmmDxe.c
> >  create mode 100644 MdeModulePkg/Include/Guid/VarCheckPolicyMmi.h
> >  create mode 100644
> > MdeModulePkg/Include/Library/VariablePolicyHelperLib.h
> >  create mode 100644 MdeModulePkg/Include/Library/VariablePolicyLib.h
> >  create mode 100644 MdeModulePkg/Include/Protocol/VariablePolicy.h
> >  create mode 100644
> > MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.inf
> >  create mode 100644
> > MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.uni
> >  create mode 100644
> > MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.i
> > nf
> >  create mode 100644
> > MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.u
> > ni
> >  create mode 100644
> > MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf
> >  create mode 100644
> > MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.uni
> >  create mode 100644
> > MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf
> >  create mode 100644
> > MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/Variable
> > Po
> > licyUnitTest.inf
> >  create mode 100644
> > MdeModulePkg/Test/ShellTest/VariablePolicyFuncTestApp/Readme.md
> >  create mode 100644
> >
> MdeModulePkg/Test/ShellTest/VariablePolicyFuncTestApp/VariablePolicyFu
> > ncTestApp.inf
> >
> > --
> > 2.26.2.windows.1.8.g01c50adf56.20200515075929
> >
> >
> >
>
>
>

 

 


Re: Soft Feature Freeze start date delays to 2020-08-24 for edk2-stable202008

Yao, Jiewen
 

To clarify below:
I just notice this one week delay. It impacts us.

https://edk2.groups.io/g/devel/message/64354
[PATCH v4 0/8] Need add a FSP binary measurement
The SecurityPkg patches have not been approved yet, and Bret and Jiewen
are still testing / discussing (as far as I understand):
<https://edk2.groups.io/g/devel/message/64526>. Material for the next
tag.

[Jiewen] I think the security pkg is already approved by me and Jian (SecurityPkg maintainer)
Bret also provides feedback that it looks good.

I request to check in to stable202008, if possible.


Thank you
Yao Jiewen



-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: Monday, August 24, 2020 9:38 PM
To: gaoliming <gaoliming@...>; 'Leif Lindholm'
<leif@...>; afish@...; Kinney, Michael D
<michael.d.kinney@...>; Guptha, Soumya K
<soumya.k.guptha@...>
Cc: devel@edk2.groups.io; announce@edk2.groups.io; 'Chang, Abner (HPS
SW/FW Technologist)' <abner.chang@...>; Zhang, Qi1
<qi1.zhang@...>; marcello.bauer@...
Subject: Re: [edk2-devel] Soft Feature Freeze start date delays to 2020-08-24 for
edk2-stable202008

Hi Liming,

On 08/24/20 03:49, gaoliming wrote:
Hi, all

Based on the discussion https://edk2.groups.io/g/devel/message/64493,
we make the conclusion to defer one week for edk2-stable202008 to
include the important patch for RiscV. Soft Feature Freeze (SFF) will
start from today (2020-08-24). Below is new edk2-stable202008 tag
planning proposed schedule
<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-
Planning>.
If you have any comments, please raise it.


Date (00:00:00 UTC-8) Description
2020-06-03 Beginning of development
2020-08-07 Feature Planning Freeze
2020-08-24 Soft Feature Freeze
2020-08-28 Hard Feature Freeze
2020-09-04 Release

Because SFF date is changed, if the patches passed code review before
SFF date (2020-08-24), the patches can still be merged for this stable
tag. Here is the patch list those passed code review before new SFF
date. For below features, I will let the feature owner decides whether
to merge it for this stable tag.
As of this writing:

- Mon Aug 24 12:59:59 UTC 2020

we've entered the (new) Soft Feature Freeze. (The SFF date is 2020-08-24
00:00:00 UTC-8; in UTC, that's Mon Aug 24 08:00:00 UTC 2020 -- about
five hours ago.)

So:

Feature List:

https://edk2.groups.io/g/devel/message/63767
[PATCH] EmbeddedPkg/libfdt: Add strncmp macro to use AsciiStrnCmp
I'm going to merge this soon (with Leif's review).

https://edk2.groups.io/g/devel/message/64363
[PATCH v5 0/3] UefiPayloadPkg: Runtime MMCONF
The UefiPayloadPkg patches in the series (#1, #3) have not received
reviews. We have to delay this until after the stable tag.

https://edk2.groups.io/g/devel/message/64354
[PATCH v4 0/8] Need add a FSP binary measurement
The SecurityPkg patches have not been approved yet, and Bret and Jiewen
are still testing / discussing (as far as I understand):
<https://edk2.groups.io/g/devel/message/64526>. Material for the next
tag.


On the other hand, I'm going to push two patches that had been reviewed
just before we entered the *delayed* SFF:

https://edk2.groups.io/g/devel/message/64345
[PATCH 1/1] OvmfPkg/Bhyve: rename files to remove 'Pkg' infix

https://edk2.groups.io/g/devel/message/62561
[PATCH] OvmfPkg/SmmControl2Dxe: negotiate
ICH9_LPC_SMI_F_CPU_HOTPLUG

Bug List:

https://edk2.groups.io/g/devel/message/50406
[PATCH 1/1] MdePkg/Include: Add missing definitions of SMBIOS type 42h in
SmBios.h

Liming, can you please merge this patch? For some reason I can't see it
in my local archives! (Only responses to it.)

https://edk2.groups.io/g/devel/message/64507
[PATCH v2 1/1] UefiCpuPkg/MpInitLib: Always initialize the DoDecrement
variable

I'm going to merge this soon.

https://edk2.groups.io/g/devel/message/64539
[PATCH] Maintainers.txt: Update Liming mail address
I'll merge this one as well.

https://edk2.groups.io/g/devel/message/64529
[PATCH] .pytool/EccCheck: Disable Ecc error code 10014 for open CI
Already merged as commit d4e0b9607c9a.


https://edk2.groups.io/g/devel/message/61938
[PATCH v2 1/1] MdePkg : UefiFileHandleLib: fix buffer overrun in
FileHandleReadLine()

I'll merge it.

Thanks!
Laszlo



TianoCore Bug Triage - APAC / NAMO - Tue, 08/25/2020 6:30pm-7:30pm #cal-reminder

devel@edk2.groups.io Calendar <devel@...>
 

Reminder: TianoCore Bug Triage - APAC / NAMO

When: Tuesday, 25 August 2020, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles

Where:https://bluejeans.com/889357567?src=join_info

View Event

Organizer: Brian Richardson brian.richardson@...

Description:

https://www.tianocore.org/bug-triage

 

Meeting URL

https://bluejeans.com/889357567?src=join_info

 

Meeting ID

889 357 567

 

Want to dial in from a phone?

Dial one of the following numbers:

+1.408.740.7256 (US (San Jose))

+1.408.317.9253 (US (Primary, San Jose))

 

(see all numbers - https://www.bluejeans.com/numbers)

Enter the meeting ID and passcode followed by #