Date   

SubRegionAuthLib RFC

Mackay, Curtis A <curtis.a.mackay@...>
 

Hi,

 

I filed a proposal for a new library to handle UEFI BIOS sub-regions at https://bugzilla.tianocore.org/show_bug.cgi?id=2808. Attached is a slide deck with design overview of the new library.

 

A UEFI BIOS sub-region is an independent signed FV that can be updated independent of UEFI BIOS on flash and is part of a pre-allocated region on flash that is visible to UEFI BIOS.

The primary use-cases for such a region would be to store independently updateable firmware and large IP configuration data files to be consumed by BIOS.

 

To maintain the integrity of the BIOS sub-region, this ticket proposes a mechanism that:

- Leverages UEFI Secure Boot to authenticate the BIOS sub-region

- Supports PKCS#7 standard as signing/authentication mechanism to maintain the integrity of sub-region in PEI, DXE or BDS Phase.

 

Please provide feedback and comments on the design.

 

Best regards,

Curtis Mackay


Re: [RFC]: StandAloneMM in OP-TEE

Mayur Gudmeti
 

Hi Sahil,

Your proposal interests us too. I got a question for you. Are you planning to use or leverage SPCI library interfaces for interaction between OP-TEE and Standalone MM?


Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

Laszlo Ersek
 

On 06/22/20 06:57, Bi, Dandan wrote:
-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
Ersek
Sent: Friday, June 19, 2020 8:48 PM
To: rfc@edk2.groups.io; Bi, Dandan <dandan.bi@intel.com>;
devel@edk2.groups.io
Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Wang,
Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Tan,
Ming <ming.tan@intel.com>
Subject: Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler:
Separate NULL class libraries for Memory and serial handlers from
MdeModulePkg/Universal/StatusCodeHandler modules

On 06/18/20 09:01, Dandan Bi wrote:
Hi All,

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

We plan to separate two kinds of NULL class libraries for Memory and serial
handlers from MdeModulePkg/Universal/StatusCodeHandler/.../
StatusCodeHandlerPei/RuntimeDxe/Smm modules.
The benefit we want to gain from this separation is to 1) make the code
clear and easy to maintain, 2) make platform flexible to choose any handler
library they need, and it also can reduce image size since the unused
handlers can be excluded.
If you have any concern or comments for this separation, please let me
know.

We plan to add new separated NULL class library
MemoryStausCodeHandlerLib and SerialStatusCodeHandlerLib with different
phase implementation into MdeModulePkg\Library\ directory.
The main tree structure may like below:
MdeModulePkg\Library
|------MemoryStausCodeHandlerLib
|------|------ PeiMemoryStausCodeHandlerLib.inf
|------|------ RuntimeDxeMemoryStatusCodeHandlerLib.inf
|------|------ SmmMemoryStausCodeHandlerLib.inf
|------SerialStatusCodeHandlerLib
|------|------ PeiSerialStatusCodeHandlerLib.inf
|------|------ RuntimeDxeSerialStatusCodeHandlerLib.inf
|------|------ SmmSerialStatusCodeHandlerLib.inf


We will update existing platform use cases in edk2 and edk2-platform repo
to cover the new NULL class library to make sure this change doesn't impact
any platform.
After this separation, StatusCodeHandler module usage will like below, and
it's also very flexible for platform to cover more handler libraries to meet
their requirements.
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.in
f {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemorySt
ausCode
NULL|HandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusC
o
NULL|deHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHan
dlerRuntimeDxe.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeM
emorySt
NULL|ausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSeri
alS
NULL|tatusCodeHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSm
m.inf {
<LibraryClasses>

NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemory
StausCode
HandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatus
Co
NULL|deHandlerLib.inf
...
}
So I assume you're going to remove PcdStatusCodeUseSerial and
PcdStatusCodeUseMemory, and when converting the existent platforms,
the new NULL class resolutions in the DSC files will reflect the specific PCD
values used in those DSC files until then. Is that right?
Thanks for pointing out the PCD part which I miss in this RFC.
This commit https://github.com/tianocore/edk2/commit/45bc28172fbf38ac21e2592c07189b55f57695e3 have updated PcdStatusCodeUseSerial and PcdStatusCodeUseMemory type.
We plan to keep PcdStatusCodeUseSerial and PcdStatusCodeUseMemory. Through NULL class resolutions in the DSC can make the code handler code included or not, then we still can control handler enable/disable through the PCD dynamically if the handler is included.
What do you think of this?
Hm... OK.

Thanks
Laszlo


Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

Dandan Bi <dandan.bi@...>
 

Hi Brian,

Personally, I prefer to add the NULL class Library to StatusCodeHandler modules.

1. I think we should make the functionality of each module clear and separated. It may also be why we added ReportStatusCodeRouter and StatusCodeHandler modules in edk2 repo before.

ReportStatusCodeRouter modules are responsible for producing Status Code Protocol/PPI and Report Status Code Handler Protocol/PPI, and StatusCodeHandler modules are responsible for producing handlers (Handlers can be provided by NULL class Libraries in this RFC).

So, that’s why I don’t want to add the NULL class Library to ReportStatusCodeRouter modules directly, which change the functionality scope of existing modules.



1. I agree that we have a lot of layers of indirection now, but what we may gain is the good modularity. And you also mentioned that one or more StatusCodeHandler Modules may be used. We also want to achieve that only the StatusCodeHandler modules in MdeModulePkg can be used after this separation, platform can only add its own handler Libs to meet its requirement.



1. As Andrew mentioned below, if add the libraries to ReportStatusCodeRouter, there will be some issue we need to fix, which seems also make the code logic a little tricky to me.



Thanks,
Dandan
From: Andrew Fish <afish@apple.com>
Sent: Saturday, June 20, 2020 2:04 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>; brian.johnson@hpe.com
Cc: Bi, Dandan <dandan.bi@intel.com>; rfc@edk2.groups.io; Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Tan, Ming <ming.tan@intel.com>
Subject: Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules




On Jun 19, 2020, at 10:29 AM, Brian J. Johnson <brian.johnson@hpe.com<mailto:brian.johnson@hpe.com>> wrote:

On 6/18/20 2:01 AM, Dandan Bi wrote:
Hi All,

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

We plan to separate two kinds of NULL class libraries for Memory and serial handlers fromMdeModulePkg/Universal/StatusCodeHandler/…/ StatusCodeHandlerPei/RuntimeDxe/Smm modules.
The benefit we want to gain from this separation is to 1) make the code clear and easy to maintain, 2) make platform flexible to choose any handler library they need, and it also can reduce image size since the unused handlers can be excluded.
If you have any concern or comments for this separation, please let me know.

We plan to add new separated NULL class library MemoryStausCodeHandlerLib and SerialStatusCodeHandlerLib with different phase implementation into MdeModulePkg\Library\ directory.
The main tree structure may like below:
MdeModulePkg\Library
|------MemoryStausCodeHandlerLib
|------|------ PeiMemoryStausCodeHandlerLib.inf
|------|------ RuntimeDxeMemoryStatusCodeHandlerLib.inf
|------|------ SmmMemoryStausCodeHandlerLib.inf
|------SerialStatusCodeHandlerLib
|------|------ PeiSerialStatusCodeHandlerLib.inf
|------|------ RuntimeDxeSerialStatusCodeHandlerLib.inf
|------|------ SmmSerialStatusCodeHandlerLib.inf


We will update existing platform use cases in edk2 and edk2-platform repo to cover the new NULL class library to make sure this change doesn’t impact any platform.
After this separation, StatusCodeHandler module usage will like below, and it’s also very flexible for platform to cover more handler libraries to meet their requirements.
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusCodeHandlerLib.inf

}

MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSerialStatusCodeHandlerLib.inf

}

MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCodeHandlerLib.inf

}


Thanks,
Dandan

Dandan,
We'll have a lot of layers of indirection.... The ReportStatusCodeRouter modules will call one or more StatusCodeHandlerModules, and the standard StatusCodeHandler modules will call multiple StatusCodeHandlerLib libraries.
How about adding StatusCodeHandlerLib support directly to the ReportStatusCodeRouter modules? Then platforms could omit the StatusCodeHandler modules if they're only using the open-source code. That sounds like less overhead since fewer modules would be needed.


I think the need to execute from ROM makes this tricky.

It looks to me that it is easy to move from PCD to libs for the StatusCodeHandler since registration is basically `RscHandlerPpi->Register (SerialStatusCodeReportWorker);`. The issue I see is the ReportStatusCodeRouter publishes RscHandlerPpi after the PEIMs constructor has been called and if the PEIM. Given globals don’t work when running from ROM you would have to do something like publish a HOB in the library constructor and then have the GenericStatusCodePeiEntry() walk the HOBs and install the handlers. So I guess it is a little easier than I 1st thought when I started writing this mail, but it would require a new public API.

Thanks,

Andrew Fish

Thanks,
--

Brian J. Johnson
Enterprise X86 Lab

Hewlett Packard Enterprise

hpe.com<x-msg://64/3D%22hpe.com%22>


Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

Dandan Bi <dandan.bi@...>
 

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
Ersek
Sent: Friday, June 19, 2020 8:48 PM
To: rfc@edk2.groups.io; Bi, Dandan <dandan.bi@intel.com>;
devel@edk2.groups.io
Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Wang,
Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Tan,
Ming <ming.tan@intel.com>
Subject: Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler:
Separate NULL class libraries for Memory and serial handlers from
MdeModulePkg/Universal/StatusCodeHandler modules

On 06/18/20 09:01, Dandan Bi wrote:
Hi All,

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

We plan to separate two kinds of NULL class libraries for Memory and serial
handlers from MdeModulePkg/Universal/StatusCodeHandler/.../
StatusCodeHandlerPei/RuntimeDxe/Smm modules.
The benefit we want to gain from this separation is to 1) make the code
clear and easy to maintain, 2) make platform flexible to choose any handler
library they need, and it also can reduce image size since the unused
handlers can be excluded.
If you have any concern or comments for this separation, please let me
know.

We plan to add new separated NULL class library
MemoryStausCodeHandlerLib and SerialStatusCodeHandlerLib with different
phase implementation into MdeModulePkg\Library\ directory.
The main tree structure may like below:
MdeModulePkg\Library
|------MemoryStausCodeHandlerLib
|------|------ PeiMemoryStausCodeHandlerLib.inf
|------|------ RuntimeDxeMemoryStatusCodeHandlerLib.inf
|------|------ SmmMemoryStausCodeHandlerLib.inf
|------SerialStatusCodeHandlerLib
|------|------ PeiSerialStatusCodeHandlerLib.inf
|------|------ RuntimeDxeSerialStatusCodeHandlerLib.inf
|------|------ SmmSerialStatusCodeHandlerLib.inf


We will update existing platform use cases in edk2 and edk2-platform repo
to cover the new NULL class library to make sure this change doesn't impact
any platform.
After this separation, StatusCodeHandler module usage will like below, and
it's also very flexible for platform to cover more handler libraries to meet
their requirements.
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.in
f {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemorySt
ausCode
NULL|HandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusC
o
NULL|deHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHan
dlerRuntimeDxe.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeM
emorySt
NULL|ausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSeri
alS
NULL|tatusCodeHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSm
m.inf {
<LibraryClasses>

NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemory
StausCode
HandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatus
Co
NULL|deHandlerLib.inf
...
}
So I assume you're going to remove PcdStatusCodeUseSerial and
PcdStatusCodeUseMemory, and when converting the existent platforms,
the new NULL class resolutions in the DSC files will reflect the specific PCD
values used in those DSC files until then. Is that right?
Thanks for pointing out the PCD part which I miss in this RFC.
This commit https://github.com/tianocore/edk2/commit/45bc28172fbf38ac21e2592c07189b55f57695e3 have updated PcdStatusCodeUseSerial and PcdStatusCodeUseMemory type.
We plan to keep PcdStatusCodeUseSerial and PcdStatusCodeUseMemory. Through NULL class resolutions in the DSC can make the code handler code included or not, then we still can control handler enable/disable through the PCD dynamically if the handler is included.
What do you think of this?


Thanks,
Dandan
I'm OK with it.

Thanks
Laszlo



Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

Dong, Eric <eric.dong@...>
 

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Brian J. Johnson
Sent: Saturday, June 20, 2020 1:29 AM
To: devel@edk2.groups.io; Bi, Dandan <dandan.bi@intel.com>; rfc@edk2.groups.io
Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Tan, Ming <ming.tan@intel.com>
Subject: Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

On 6/18/20 2:01 AM, Dandan Bi wrote:
Hi All,

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

We plan to separate two kinds of NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler/.../ StatusCodeHandlerPei/RuntimeDxe/Smm modules.
The benefit we want to gain from this separation is to 1) make the code clear and easy to maintain, 2) make platform flexible to choose any handler library they need, and it also can reduce image size since the unused handlers can be excluded.
If you have any concern or comments for this separation, please let me know.

We plan to add new separated NULL class library MemoryStausCodeHandlerLib and SerialStatusCodeHandlerLib with different phase implementation into MdeModulePkg\Library\ directory.
The main tree structure may like below:
MdeModulePkg\Library
|------MemoryStausCodeHandlerLib
|------|------ PeiMemoryStausCodeHandlerLib.inf
|------|------ RuntimeDxeMemoryStatusCodeHandlerLib.inf
|------|------ SmmMemoryStausCodeHandlerLib.inf
|------SerialStatusCodeHandlerLib
|------|------ PeiSerialStatusCodeHandlerLib.inf
|------|------ RuntimeDxeSerialStatusCodeHandlerLib.inf
|------|------ SmmSerialStatusCodeHandlerLib.inf


We will update existing platform use cases in edk2 and edk2-platform repo to cover the new NULL class library to make sure this change doesn't impact any platform.
After this separation, StatusCodeHandler module usage will like below, and it's also very flexible for platform to cover more handler libraries to meet their requirements.
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusCodeHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSerialStatusCodeHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCodeHandlerLib.inf
...
}


Thanks,
Dandan



Dandan,

We'll have a lot of layers of indirection.... The ReportStatusCodeRouter modules will call one or more StatusCodeHandlerModules, and the standard StatusCodeHandler modules will call multiple StatusCodeHandlerLib libraries.

How about adding StatusCodeHandlerLib support directly to the ReportStatusCodeRouter modules? Then platforms could omit the StatusCodeHandler modules if they're only using the open-source code. That sounds like less overhead since fewer modules would be needed



Hi Brain,

You are right. Current design truly has a lot of layers. The ReportStatusCodeRouter module provides the register logic and maintain the registered status code handlers. Now the platform may have more than one of drivers used to register the status code handler. This RFC used to resolve the platform has more than one status code handler drivers' issue. We expect the platform only need one wrapper driver in MdeModulePkg to let the status code handler library to register its handler on it.

Thanks,

Eric



Thanks,
--

Brian J. Johnson
Enterprise X86 Lab

Hewlett Packard Enterprise

hpe.com<3D%22hpe.com%22>


Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

Andrew Fish <afish@...>
 

On Jun 19, 2020, at 10:29 AM, Brian J. Johnson <brian.johnson@hpe.com> wrote:

On 6/18/20 2:01 AM, Dandan Bi wrote:
Hi All,

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

We plan to separate two kinds of NULL class libraries for Memory and serial handlers fromMdeModulePkg/Universal/StatusCodeHandler/…/ StatusCodeHandlerPei/RuntimeDxe/Smm modules.
The benefit we want to gain from this separation is to 1) make the code clear and easy to maintain, 2) make platform flexible to choose any handler library they need, and it also can reduce image size since the unused handlers can be excluded.
If you have any concern or comments for this separation, please let me know.

We plan to add new separated NULL class library MemoryStausCodeHandlerLib and SerialStatusCodeHandlerLib with different phase implementation into MdeModulePkg\Library\ directory.
The main tree structure may like below:
MdeModulePkg\Library
|------MemoryStausCodeHandlerLib
|------|------ PeiMemoryStausCodeHandlerLib.inf
|------|------ RuntimeDxeMemoryStatusCodeHandlerLib.inf
|------|------ SmmMemoryStausCodeHandlerLib.inf
|------SerialStatusCodeHandlerLib
|------|------ PeiSerialStatusCodeHandlerLib.inf
|------|------ RuntimeDxeSerialStatusCodeHandlerLib.inf
|------|------ SmmSerialStatusCodeHandlerLib.inf


We will update existing platform use cases in edk2 and edk2-platform repo to cover the new NULL class library to make sure this change doesn’t impact any platform.
After this separation, StatusCodeHandler module usage will like below, and it’s also very flexible for platform to cover more handler libraries to meet their requirements.
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusCodeHandlerLib.inf

}

MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSerialStatusCodeHandlerLib.inf

}

MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCodeHandlerLib.inf

}


Thanks,
Dandan
Dandan,

We'll have a lot of layers of indirection.... The ReportStatusCodeRouter modules will call one or more StatusCodeHandlerModules, and the standard StatusCodeHandler modules will call multiple StatusCodeHandlerLib libraries.

How about adding StatusCodeHandlerLib support directly to the ReportStatusCodeRouter modules? Then platforms could omit the StatusCodeHandler modules if they're only using the open-source code. That sounds like less overhead since fewer modules would be needed.

I think the need to execute from ROM makes this tricky.

It looks to me that it is easy to move from PCD to libs for the StatusCodeHandler since registration is basically `RscHandlerPpi->Register (SerialStatusCodeReportWorker);`. The issue I see is the ReportStatusCodeRouter publishes RscHandlerPpi after the PEIMs constructor has been called and if the PEIM. Given globals don’t work when running from ROM you would have to do something like publish a HOB in the library constructor and then have the GenericStatusCodePeiEntry() walk the HOBs and install the handlers. So I guess it is a little easier than I 1st thought when I started writing this mail, but it would require a new public API.

Thanks,

Andrew Fish
Thanks,

--
Brian J. Johnson
Enterprise X86 Lab

Hewlett Packard Enterprise

hpe.com <x-msg://64/3D%22hpe.com%22>


Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

Brian J. Johnson
 

On 6/18/20 2:01 AM, Dandan Bi wrote:

Hi All,

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2816 <https://bugzilla.tianocore.org/show_bug.cgi?id=2816>

We plan to separate two kinds of NULL class libraries for Memory and serial handlers from *MdeModulePkg/Universal/StatusCodeHandler/…/ StatusCodeHandlerPei/RuntimeDxe/Smm* modules.

The benefit we want to gain from this separation is to 1) make the code clear and easy to maintain, 2) make platform flexible to choose any handler library they need, and it also can reduce image size since the unused handlers can be excluded.

If you have any concern or comments for this separation, please let me know.

We plan to add new separated NULL class library *MemoryStausCodeHandlerLib *and*SerialStatusCodeHandlerLib *with different phase implementation into *MdeModulePkg\Library\* directory.

The main tree structure may like below:

MdeModulePkg\Library

|------*MemoryStausCodeHandlerLib*

|------|------ PeiMemoryStausCodeHandlerLib.inf

|------|------ RuntimeDxeMemoryStatusCodeHandlerLib.inf

|------|------ SmmMemoryStausCodeHandlerLib.inf

|------*SerialStatusCodeHandlerLib*

|------|------ PeiSerialStatusCodeHandlerLib.inf

|------|------ RuntimeDxeSerialStatusCodeHandlerLib.inf

|------|------ SmmSerialStatusCodeHandlerLib.inf

**

**

We will update existing platform use cases in edk2 and edk2-platform repo to cover the new NULL class library to make sure this change doesn’t impact any platform.

After this separation, StatusCodeHandler module usage will like below, and it’s also very flexible for platform to cover more handler libraries to meet their requirements.

MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {

  <LibraryClasses>

NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeHandlerLib.inf

NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusCodeHandlerLib.inf

    …

}

MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf {

  <LibraryClasses>

NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeMemoryStausCodeHandlerLib.inf

NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSerialStatusCodeHandlerLib.inf

    …

}

MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf {

  <LibraryClasses>

 NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemoryStausCodeHandlerLib.inf

NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCodeHandlerLib.inf

    …

}

Thanks,

Dandan
Dandan,

We'll have a lot of layers of indirection....  The ReportStatusCodeRouter modules will call one or more StatusCodeHandlerModules, and the standard StatusCodeHandler modules will call multiple StatusCodeHandlerLib libraries.

How about adding StatusCodeHandlerLib support directly to the ReportStatusCodeRouter modules?  Then platforms could omit the StatusCodeHandler modules if they're only using the open-source code.  That sounds like less overhead since fewer modules would be needed.

Thanks,

--

*Brian J. Johnson
*Enterprise X86 Lab

Hewlett Packard Enterprise

*hpe.com* <3D"hpe.com">


Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

Laszlo Ersek
 

On 06/18/20 09:01, Dandan Bi wrote:
Hi All,

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

We plan to separate two kinds of NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler/.../ StatusCodeHandlerPei/RuntimeDxe/Smm modules.
The benefit we want to gain from this separation is to 1) make the code clear and easy to maintain, 2) make platform flexible to choose any handler library they need, and it also can reduce image size since the unused handlers can be excluded.
If you have any concern or comments for this separation, please let me know.

We plan to add new separated NULL class library MemoryStausCodeHandlerLib and SerialStatusCodeHandlerLib with different phase implementation into MdeModulePkg\Library\ directory.
The main tree structure may like below:
MdeModulePkg\Library
|------MemoryStausCodeHandlerLib
|------|------ PeiMemoryStausCodeHandlerLib.inf
|------|------ RuntimeDxeMemoryStatusCodeHandlerLib.inf
|------|------ SmmMemoryStausCodeHandlerLib.inf
|------SerialStatusCodeHandlerLib
|------|------ PeiSerialStatusCodeHandlerLib.inf
|------|------ RuntimeDxeSerialStatusCodeHandlerLib.inf
|------|------ SmmSerialStatusCodeHandlerLib.inf


We will update existing platform use cases in edk2 and edk2-platform repo to cover the new NULL class library to make sure this change doesn't impact any platform.
After this separation, StatusCodeHandler module usage will like below, and it's also very flexible for platform to cover more handler libraries to meet their requirements.
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusCodeHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSerialStatusCodeHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCodeHandlerLib.inf
...
}
So I assume you're going to remove PcdStatusCodeUseSerial and
PcdStatusCodeUseMemory, and when converting the existent platforms, the
new NULL class resolutions in the DSC files will reflect the specific
PCD values used in those DSC files until then. Is that right?

I'm OK with it.

Thanks
Laszlo


[edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

Dandan Bi <dandan.bi@...>
 

Hi All,

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

We plan to separate two kinds of NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler/.../ StatusCodeHandlerPei/RuntimeDxe/Smm modules.
The benefit we want to gain from this separation is to 1) make the code clear and easy to maintain, 2) make platform flexible to choose any handler library they need, and it also can reduce image size since the unused handlers can be excluded.
If you have any concern or comments for this separation, please let me know.

We plan to add new separated NULL class library MemoryStausCodeHandlerLib and SerialStatusCodeHandlerLib with different phase implementation into MdeModulePkg\Library\ directory.
The main tree structure may like below:
MdeModulePkg\Library
|------MemoryStausCodeHandlerLib
|------|------ PeiMemoryStausCodeHandlerLib.inf
|------|------ RuntimeDxeMemoryStatusCodeHandlerLib.inf
|------|------ SmmMemoryStausCodeHandlerLib.inf
|------SerialStatusCodeHandlerLib
|------|------ PeiSerialStatusCodeHandlerLib.inf
|------|------ RuntimeDxeSerialStatusCodeHandlerLib.inf
|------|------ SmmSerialStatusCodeHandlerLib.inf


We will update existing platform use cases in edk2 and edk2-platform repo to cover the new NULL class library to make sure this change doesn't impact any platform.
After this separation, StatusCodeHandler module usage will like below, and it's also very flexible for platform to cover more handler libraries to meet their requirements.
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusCodeHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSerialStatusCodeHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCodeHandlerLib.inf
...
}


Thanks,
Dandan


Re: [edk2-devel] [edk2-rfc] [RFCv2] code-first process for UEFI-forum specifications

Samer El-Haj-Mahmoud
 

Leif,

I received additional feedback on this proposal.

We should add the UEFI Shell Specification to this new process. This includes adding a bugzilla.tianocore.org product category and a new Github repository for the "UEFI Shell Specification".

Thanks,
--Samer

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer El-
Haj-Mahmoud via groups.io
Sent: Wednesday, May 20, 2020 6:19 AM
To: rfc@edk2.groups.io; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@arm.com>; ray.ni@intel.com; leif@nuviainc.com;
devel@edk2.groups.io
Cc: Felixp@ami.com; Doran, Mark <mark.doran@intel.com>; Andrew Fish
<afish@apple.com>; Laszlo Ersek <lersek@redhat.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@arm.com>
Subject: Re: [edk2-devel] [edk2-rfc] [RFCv2] code-first process for UEFI-forum
specifications

Are there any additional comments on the code first process for UEFI
specifications?

When should we expect the process to *actually* start being used?

Thanks,
--Samer

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Samer
El-Haj- Mahmoud via groups.io
Sent: Thursday, May 14, 2020 5:11 PM
To: rfc@edk2.groups.io; ray.ni@intel.com; leif@nuviainc.com;
devel@edk2.groups.io
Cc: Felixp@ami.com; Doran, Mark <mark.doran@intel.com>; Andrew Fish
<afish@apple.com>; Laszlo Ersek <lersek@redhat.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@arm.com>
Subject: Re: [edk2-rfc] [RFCv2] code-first process for UEFI-forum
specifications

Leif, Ray,

I have not seen any discussion on this thread since March(!)...

Please see my comments below.


-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Ni, Ray
via Groups.Io
Sent: Wednesday, March 25, 2020 1:15 AM
To: rfc@edk2.groups.io; leif@nuviainc.com; devel@edk2.groups.io
Cc: Felixp@ami.com; Doran, Mark <mark.doran@intel.com>; Andrew Fish
<afish@apple.com>; Laszlo Ersek <lersek@redhat.com>; Kinney, Michael
D <michael.d.kinney@intel.com>
Subject: Re: [edk2-rfc] [RFCv2] code-first process for UEFI-forum
specifications


## Github
New repositories will be added for holding the text changes and
the source
code.

Specification text changes will be held within the affected source
repository, in the Github flavour of markdown, in a file (or split
across several files) with .md suffix.
What's the case when multiple .MD files are needed?

(This one may break down where we have a specification change
affecting multiple specifications, but at that point we can track
it with multiple BZ entries)


## Source code
In order to ensure draft code does not accidentally leak into
production use, and to signify when the changeover from draft to
final happens, *all* new or modified[1] identifiers need to be
prefixed with the
relevant BZ####.

[1] Modified in a non-backwards-compatible way. If, for example, a
statically
sized array is grown - this does not need to be prefixed. But
a tag in a comment would be *highly* recommended.
If a protocol is enhanced to provide more interfaces with increased
revision number, would you like the protocol name to be prefixed
with
BZ####?
Or just the new interfaces added to the protocol are prefixed the BZ####?
I think just prefixing the new interfaces can meet the purpose.
I think pre-fixing the new interfaces is sufficient. Otherwise, you
need to modify all code using the existing interfaces (for build
verification)


But the protocol definition is changed, it also needs to be prefixed
according to this flow.
Can you clarify a bit more?
A changed protocol definition is not backwards compatible, and
typically results in a new protocol GUID. In that case, it really
becomes a new definition and need to be pre-fixed per this rule. Right?


### File names
New public header files need the prefix. I.e.
`Bz1234MyNewProtocol.h` Private header files do not need the prefix.

### Contents

The tagging must follow the coding style used by each affected codebase.
Examples:

| Released in spec | Draft version in tree | Comment |
| --- | --- | --- |
| `FunctionName` | `Bz1234FunctionName` | |
| `HEADER_MACRO` | `BZ1234_HEADER_MACRO` |
|

If FunctionName or HEADER_MACRO is defined in non-public header
files, I don't think they require the prefix. Do you agree?

For data structures or enums, any new or non-backwards-compatible
structs or fields require a prefix. As above, growing an existing
array in an existing struct requires no prefix.

| `typedef SOME_STRUCT` | `BZ1234_SOME_STRUCT` | Typedef only
[2] |
| `StructField` | `Bz1234StructField` | In existing struct[3] |
| `typedef SOME_ENUM` | `BZ1234_SOME_ENUM` | Typedef only
[2] |

[2] If the struct or enum definition is separate from the typedef
in the
public
header, the definition does not need the prefix.
What does "separate" mean?
Does it mean "struct or enum in the public header BzXXX.h don't need
the prefix"?
If yes, then I think macros defined in BzXXX.h also don't need the prefix.

[3] Individual fields in newly added typedefd struct do not need
prefix,
the
struct already carried the prefix.

Variable prefixes indicating global scope ('g' or 'm') go before
the BZ
prefix.

| `gSomeGuid` | `gBz1234SomeGuid` | |

Local identifiers, including module-global ones (m-prefixed) do
not require a BZ prefix.
I think only the names (struct type name, enum type name, interface
name, protocol/ppi name) defined in public header files need the BZ
prefix when the public header doesn't have prefix.
Right?
The way I read it, *all* new (and non-backward modified) identifiers
(typedef struct, typedef enum, and new structfield in existing struct)
need to be pre-fixed, regardless if the filename is prefixed or not.
Correct?


IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the contents to any other person, use it for any purpose, or store or
copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Bret Barkelew <bret.barkelew@...>
 

Rebecca,

I was able to confirm that it was an issue with Git for Windows. Looks like it’s fixed in current snapshots and will be in the next release:
https://github.com/git-for-windows/git/issues/2598

Also, ATTN: @Michael Kubacki<mailto:Michael.Kubacki@microsoft.com>

- Bret

From: Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>
Sent: Wednesday, May 27, 2020 10:45 AM
To: Rebecca Cran<mailto:rebecca@bsdio.com>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@redhat.com<mailto:lersek@redhat.com>; Andrew Fish<mailto:afish@apple.com>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@outlook.com<mailto:spbrogan@outlook.com>; Desimone, Nathaniel L<mailto:nathaniel.l.desimone@intel.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; Leif Lindholm (Nuvia address)<mailto:leif@nuviainc.com>
Subject: RE: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

That’s not a bad idea: I should try with my WSL install.

I’m on the same version of Git for Windows, and think I’ll open it as an issue to the maintainer.

For now, going though the paces is just as useful to me as getting a viable environment (after all, PRs soon!), so I don’t mind trying another OS or install if that’s what it takes.

- Bret

From: Rebecca Cran<mailto:rebecca@bsdio.com>
Sent: Wednesday, May 27, 2020 9:07 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@redhat.com<mailto:lersek@redhat.com>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>; Andrew Fish<mailto:afish@apple.com>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@outlook.com<mailto:spbrogan@outlook.com>; Desimone, Nathaniel L<mailto:nathaniel.l.desimone@intel.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; Leif Lindholm (Nuvia address)<mailto:leif@nuviainc.com>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

On 5/27/2020 6:12 AM, Laszlo Ersek wrote:

So, it could be a MINGW64 packaging bug, perhaps.
I'm getting the same error, but with a different packaging of Git:
mine's in C:\Program Files\Git\cmd\git.exe .

It's version "git version 2.26.2.windows.1".

Of course it's possible it's just the same MINGW version that's been put
into its own installer.


I also tried using my openSUSE WSL installation, but it failed with:

STARTTLS failed! SSL connect attempt failed error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed at
/usr/lib/git/git-send-email line 1548.


So I ended up copying it to one of my FreeBSD systems and sent it from
there.


--
Rebecca Cran


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Laszlo Ersek
 

On 05/28/20 00:07, Rebecca Cran wrote:

I also tried using my openSUSE WSL installation, but it failed with:

STARTTLS failed! SSL connect attempt failed error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed at
/usr/lib/git/git-send-email line 1548.
That's different -- in this case, peer certificate verification was
attempted, but it failed, because the root certificate in the peer's
cert chain is not trusted by your system (your openSUSE WSL environment).

The fix for that should be identical to what you'd do on a standalone
openSUSE installation -- (1) figure out what CA cert is the root of the
peer's cert chain, and (2) decide consciously whether you trust that CA
cert to sign other certificates, (3) import said CA cert persistently
into your "store of trusted CA certs".

Examples:

(1) I think one command that works is:

$ openssl s_client -showcerts -connect HOST:PORT </dev/null

(2) up to you :)

(3a) On RHEL, this would mean copying the CA certificate under
"/etc/pki/ca-trust/source/anchors/", in PEM format, and then running the
"update-ca-trust extract" command. (Both actions need root (uid=0)
access, of course.)

(3b) For a user session (i.e., not system-wide), git-send-email also
takes "--smtp-ssl-cert-path":

--smtp-ssl-cert-path
Path to a store of trusted CA certificates for SMTP SSL/TLS
certificate validation (either a directory that has been
processed by c_rehash, or a single file containing one or
more PEM format certificates concatenated together: see
verify(1) -CAfile and -CApath for more information on
these). Set it to an empty string to disable certificate
verification. Defaults to the value of the
sendemail.smtpsslcertpath configuration variable, if set,
or the backing SSL library's compiled-in default otherwise
(which should be the best choice on most platforms).

Thanks
Laszlo


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Bret Barkelew <bret.barkelew@...>
 

That’s not a bad idea: I should try with my WSL install.

I’m on the same version of Git for Windows, and think I’ll open it as an issue to the maintainer.

For now, going though the paces is just as useful to me as getting a viable environment (after all, PRs soon!), so I don’t mind trying another OS or install if that’s what it takes.

- Bret

From: Rebecca Cran<mailto:rebecca@bsdio.com>
Sent: Wednesday, May 27, 2020 9:07 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@redhat.com<mailto:lersek@redhat.com>; Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>; Andrew Fish<mailto:afish@apple.com>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@outlook.com<mailto:spbrogan@outlook.com>; Desimone, Nathaniel L<mailto:nathaniel.l.desimone@intel.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; Leif Lindholm (Nuvia address)<mailto:leif@nuviainc.com>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

On 5/27/2020 6:12 AM, Laszlo Ersek wrote:

So, it could be a MINGW64 packaging bug, perhaps.
I'm getting the same error, but with a different packaging of Git:
mine's in C:\Program Files\Git\cmd\git.exe .

It's version "git version 2.26.2.windows.1".

Of course it's possible it's just the same MINGW version that's been put
into its own installer.


I also tried using my openSUSE WSL installation, but it failed with:

STARTTLS failed! SSL connect attempt failed error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed at
/usr/lib/git/git-send-email line 1548.


So I ended up copying it to one of my FreeBSD systems and sent it from
there.


--
Rebecca Cran


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Andrew Fish <afish@...>
 

Rebecca,

I cheated and used smtpServer = relay.apple.com and smtpEncryption = tls. Seems relay.apple.com does not require authentication and it just worked.

I used an internal git mailing list to figure all this out, but seems the easy button was an smtpServer setup to be easy to use with git sendmail. It might be worth while to have folks reach out inside their companies to see if there are existing known good recipes?

Thanks,

Andrew Fish

On May 27, 2020, at 3:07 PM, Rebecca Cran <rebecca@bsdio.com> wrote:

On 5/27/2020 6:12 AM, Laszlo Ersek wrote:

So, it could be a MINGW64 packaging bug, perhaps.
I'm getting the same error, but with a different packaging of Git: mine's in C:\Program Files\Git\cmd\git.exe .

It's version "git version 2.26.2.windows.1".

Of course it's possible it's just the same MINGW version that's been put into its own installer.


I also tried using my openSUSE WSL installation, but it failed with:

STARTTLS failed! SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at /usr/lib/git/git-send-email line 1548.


So I ended up copying it to one of my FreeBSD systems and sent it from there.


--
Rebecca Cran





Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Rebecca Cran
 

On 5/27/2020 6:12 AM, Laszlo Ersek wrote:

So, it could be a MINGW64 packaging bug, perhaps.
I'm getting the same error, but with a different packaging of Git: mine's in C:\Program Files\Git\cmd\git.exe .

It's version "git version 2.26.2.windows.1".

Of course it's possible it's just the same MINGW version that's been put into its own installer.


I also tried using my openSUSE WSL installation, but it failed with:

STARTTLS failed! SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at /usr/lib/git/git-send-email line 1548.


So I ended up copying it to one of my FreeBSD systems and sent it from there.


--
Rebecca Cran


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Laszlo Ersek
 

On 05/27/20 03:52, Bret Barkelew wrote:
So, today I followed the Wiki (that I had never seen) and now I’m staring down the barrel of this fellow…
[cid:image002.png@01D6338E.D6C64920]

[Not using SSL_VERIFY_PEER due to out-of-date IO::Socket::SSL.
To use SSL please install IO::Socket::SSL with version>=2.007 at /usr/share/perl5/core_perl/Net/SMTP.pm line 270.]

Anyone have thoughts? I’mma go get a scotch.
I think your perl installation and your git installation may come from
different sources, and the perl install may not satisfy the git
install's dependencies.

In GNU/Linux distribution lingo, I'd call this either a distribution
error, or (maybe more precisely) a git package error. Normally the git
package should spell out the pre-requisite package names, along with the
minimum required package version(s). And the package manager should
enforce that, when installing git.

Other people appear to have encountered a similiar issue before:

https://github.com/Homebrew/homebrew-core/issues/24210#issuecomment-366831944

https://github.com/msys2/MSYS2-packages/issues/1152

https://bugs.archlinux.org/task/54326

https://bugs.archlinux.org/task/62948


When I check on my laptop now, I see:

$ rpm --query --requires git-email
[...]
perl(Net::SMTP::SSL)
[...]

and recursively,

$ rpm --query --requires perl-Net-SMTP-SSL
[...]
perl(IO::Socket::SSL)
[...]

In other words, whenever it was that I ran "yum install git-email" (for
gaining access to the "git-send-email" command), yum made sure that
"perl-Net-SMTP-SSL" and "perl-IO-Socket-SSL" would both be pulled in.

(Assuming the RPM spec files spelled out minimum versions on the
dependencies, yum would enforce those particular versions too.)

So, it could be a MINGW64 packaging bug, perhaps.

Thanks,
Laszlo


Re: PKCS7 Authenticated Variable Enrollment

Guomin Jiang
 

I am sorry that I have not the use case, and I plan to investigating it after August.

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of
divneil.r.wadhawan@intel.com
Sent: Wednesday, May 27, 2020 6:54 PM
To: Jiang, Guomin <guomin.jiang@intel.com>; rfc@edk2.groups.io
Subject: Re: [edk2-rfc] PKCS7 Authenticated Variable Enrollment

Hi Goumin,

I had discussion internally, and I got hold off tools from:
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git.
It is generating the correct format as per
EFI_VARIABLE_AUTHENTICATION_2.

So, I thought of first validating RSA2048 Sign verification and it is failing.
I still have to figure out that. Do you have a working use case which uses
PKCS7 format and PKCS7_verify works?

Regards,
Divneil


Re: PKCS7 Authenticated Variable Enrollment

Wadhawan, Divneil R
 

Hi Goumin,

I had discussion internally, and I got hold off tools from: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git.
It is generating the correct format as per EFI_VARIABLE_AUTHENTICATION_2.

So, I thought of first validating RSA2048 Sign verification and it is failing.
I still have to figure out that. Do you have a working use case which uses PKCS7 format and PKCS7_verify works?

Regards,
Divneil


Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

Tomas Pilar (tpilar)
 

This will probably be down to the [send-email] section of git config, do you have smtpEncryption enabled by any chance?

You could also try updating the required package:
perl -MCPAN -e 'install "IO::Socket::SSL"'

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Bret Barkelew via groups.io
Sent: 27 May 2020 02:53
To: Andrew Fish <afish@apple.com>; Laszlo Ersek <lersek@redhat.com>
Cc: devel@edk2.groups.io; spbrogan@outlook.com; rfc@edk2.groups.io; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm (Nuvia address) <leif@nuviainc.com>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

So, today I followed the Wiki (that I had never seen) and now I'm staring down the barrel of this fellow...
[cid:image001.png@01D63411.7C958370]

[Not using SSL_VERIFY_PEER due to out-of-date IO::Socket::SSL.
To use SSL please install IO::Socket::SSL with version>=2.007 at /usr/share/perl5/core_perl/Net/SMTP.pm line 270.]

Anyone have thoughts? I'mma go get a scotch.

- Bret

From: Andrew Fish<mailto:afish@apple.com>
Sent: Monday, May 25, 2020 11:28 AM
To: Laszlo Ersek<mailto:lersek@redhat.com>
Cc: Bret Barkelew<mailto:Bret.Barkelew@microsoft.com>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@outlook.com<mailto:spbrogan@outlook.com>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Desimone, Nathaniel L<mailto:nathaniel.l.desimone@intel.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; Leif Lindholm (Nuvia address)<mailto:leif@nuviainc.com>
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process



On May 25, 2020, at 11:10 AM, Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>> wrote:

Hi Andrew,

On 05/25/20 06:09, Andrew Fish wrote:

I also found I had to Bing/Google to find the detailed instructions I
needed as a developer, as the Wiki seems to assume you just know the
Linux kernel patch process. That feels like an area we can improve.
(apologies if I've lost context; please disregard my message below in
that case).

I wrote the following wiki article originally in 2016:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FLaszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers&;data=02%7C01%7CBret.Barkelew%40microsoft.com%7C2e084613c24f433ca0a508d800d978de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637260281325061578&amp;sdata=nIMHQLnu8F%2F%2BTMMsLKVXbWnO6AWE9WuUu5k1TK4HgTQ%3D&amp;reserved=0

I wrote it specifically for developers & maintainers with no (or almost
no) prior git / mailing list experience. Multiple developers confirmed
later that the article had helped them.
Laszlo,

Your wiki article was very very helpful. I just could not find it from the Tianocre wiki. It would be good if we could link to it from here [1], maybe as add to this: "Are you new to using git? If so, then the New to git page may be helpful."?

There are a lot folks who use git but don't use the email based review so they have never setup git with emali before. Your wiki, plus me figuring out the magic internal SMTP reflector (I reached out on an internal git malling list) is what got me unblocked.

[1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FEDK-II-Development-Process&;data=02%7C01%7CBret.Barkelew%40microsoft.com%7C2e084613c24f433ca0a508d800d978de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637260281325061578&amp;sdata=XPx6jrloPC9LW0iCecZuFmaz3JgjCSQYeF0PEyGW4I0%3D&amp;reserved=0

Thanks,

Andrew Fish

Thanks
Laszlo

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

381 - 400 of 738