Date   

Re: SubRegionAuthLib RFC

Laszlo Ersek
 

On 06/25/20 21:25, Sukerkar, Amol N wrote:
Hi Laszlo,

Please see my comments below.

Thanks,
Amol

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Thursday, June 25, 2020 4:57 AM
To: rfc@edk2.groups.io; Mackay, Curtis A <curtis.a.mackay@...>
Cc: Kinney, Michael D <michael.d.kinney@...>; Wang, Jian J <jian.j.wang@...>; Yao, Jiewen <jiewen.yao@...>; Sukerkar, Amol N <amol.n.sukerkar@...>; Agrawal, Sachin <sachin.agrawal@...>
Subject: Re: [edk2-rfc] SubRegionAuthLib RFC

Hi,

On 06/19/20 18:55, Mackay, Curtis A wrote:
Friendly reminder to review and provide feedback on the RFC. We are looking to target a WW34 deadline with this design.
I don't have a stake in this feature, but because the presentation isn't long, I've briefly skimmed it:

- It's unclear whether the public data structures describe a wire format. If they do, they should be packed, IMO.
[ANS] We tries to follow the precedence in other EDK2 implementation. Any suggestions to improve are welcome.
Well as far as I'm concerned it's a simple rule. If a structure is
serialized from RAM into a disk file, or to the network, then the
structure should be packed. If it's only exchanged in RAM, on a single
computer, between modules that all conform to the UEFI spec (which
dictates natural alignment for structure members), then fields in the
structure should not be packed.


- The struct hack (SUB_REGION_VERIFICATION.CertData being an array with
1 element) is not ideal, in my opinion. Especially because SUB_REGION_VERIFICATION is embedded in EFI_SUB_REGION_AUTHENTICATION afterwards. Personally I prefer comments to the struct hack that explain where the CertData starts. Out-of-bounds subscripts for CertData -- having just one element -- are dubious; we shouldn't have more of that (IMO).
[ANS] You can ignore SIGNED_SUB_REGION for now. The only intention here is to show that EFI_SUB_REGION_AUTHENTICATION is the header (with signature) and void *blob is the payload. So, even if you consider SUB_REGION_VERIFICATION as a member of EFI_SUB_REGION_AUTHENTICATION struct, CertData is still at the bottom of the struct stack. And depending on the type of signature the size will vary. But due to the nature of signature as PKCS#7, openssl API will be able to parse it. How do you propose we improve the struct?
The struct hack is not desirable because a snippet like

SUB_REGION_VERIFICATION *Verification;
UINT8 Value;

Verification = ...;
Value = Verification->CertData[1];

is undefined behavior. The compiler knows that CertData has 1 element,
IOW that subscript 1 is out of bounds for the array. Compilers get ever
more aggressive in exploiting undefined behavior, so we should not
introduce more of it.

Simply remove the CertData field from the structure, and replace it with
a comment that states (in natural language) more or less the same. For
an example, refer to the "Description", "FilePathList" and
"OptionalData" fields in EFI_LOAD_OPTION, in file
"MdePkg/Include/Uefi/UefiSpec.h". (Or, in the matching part of the UEFI
2.8 spec itself -- "3.1.3 Load Options".)


- it's unclear whether EFI_SUB_REGION_AUTHENTICATION.Name is supposed to be NUL-terminated, or not.
[ANS] Name is stored in a bounded array. It uses memcmp to validate which is limited to MAX_NAME bytes. If it exceeds and corrupts VendorGuid, the authentication will fail since VendorGuid is part of data over which signature is calculated.
That makes sense, but a comment should document it.


- "char" is not a good element type for
EFI_SUB_REGION_AUTHENTICATION.Name. If we want it to be "text", then it should either be CHAR8 or CHAR16. If we want it to be any binary string, then it should be UINT8.
[ANS] Agree.

- the EFI_ prefix is used inconsistently on the type names (not sure if that's intentional -- I can't tell the principle behind the current use)
[ANS] Could you suggest how we can make it compliant here?
My point was *not* whether the EFI_ prefix should be used, or should not
be used, for the structures introduced for this feature.

Instead, my point was that either *all* of the new structures should use
_EFI, or *none* should.

- SUB_REGION_HEADER: no EFI_ prefix
- SUB_REGION_VERIFICATION: no EFI_ prefix
- EFI_SUB_REGION_AUTHENTICATION: yes EFI_ prefix
- SIGNED_SUB_REGION: no EFI_ prefix

My suggestion is to either prepend EFI_ to SUB_REGION_HEADER,
SUB_REGION_VERIFICATION, and SIGNED_SUB_REGION, *or* to strip the prefix
from EFI_SUB_REGION_AUTHENTICATION. Whichever you choose is up to
whether this feature is going to be standardized. But, either way, the
prefix usage should be consistent.


- in SIGNED_SUB_REGION, the field names are not aligned with each other, and edk2 uses VOID spelling rather than "void". Also "blob" should be CamelCased as "Blob".
[ANS] Agree. Needs to change.

- The size of the entire region is not encoded (in a generic way,
anyway) in the structures. Is this intentional perhaps?
[ANS] SUB_REGION_HEADER.Length = sizeof(SUB_REGION_HEADER) + sizeof (CertData). Do you think anything else needs to be done?
I have three concerns with this:

(1) The expression you provided does not take into account any possible
padding between the Hdr field and the CertData field. (See also my note
on packing.) So minimally, we should say

Verification.Hdr.Length = (OFFSET_OF (
SUB_REGION_VERIFICATION,
CertData
) +
CertDataBytes);

(2) Are we sure a UINT16 length field can cover all CertData fields
encountered in practice? Will there ever be a CertData that's larger
than ~64KB?

(3) But, my question actually relates to the size of the Blob field.
SIGNED_SUB_REGION expresses the base address of the region, but not the
size thereof. Is that intentional?

- in the AuthenticateSubRegion() prototype, SignedSubRegionSize has type UINTN, but (*SubRegionDataSize) has type UINT32. I think these types should be the same.
[ANS] Agree. Needs to change.

- same for SignedSubRegionImage and (*SubRegionDataBuffer): (UINT8*) vs.
(VOID*)
[ANS] Agree.

- the ownership of the output (*SubRegionDataBuffer) is unclear. Is it a pointer into the input buffer? Is it a copy, allocated dynamically?
[ANS] it is a pointer to original sub-region data (without signature header). If authentication is unsuccessful, it will be NULL. But, I agree AuthenticateSubRegion should just authenticate the sub-region. Parsing the data should be left to the caller.
I think the general idea behind the current prototype is fine -- take an
input (base, size) pair, and adjust both components of that pair on
output. That's OK, in my opinion.

It's just that the caller needs to know that the output pointer points
into the same original blob (in other words, that on success,
(*SubRegionDataBuffer) *aliases* SignedSubRegionImage).

This is relevant to avoid memory management errors (double freeing of
buffers, or memory leaks). Every function ever that outputs a pointer,
needs to explain in a comment to the caller, who is responsible for
freeing the pointed-to object.

Thanks
Laszlo


Re: SubRegionAuthLib RFC

Sean
 

Curtis,

Not sure I fully follow your proposal. Can you provide more on the use case? Is the "blob" a FV or is the signed_sub_region a raw section in a ffs file? or something else like binary at flash offset?

The PI spec has a filesystem that describes many options and the DxeCore has support for security validation / authentication state flags associated with FVs and FFS files.

I have also seen many designs that leverage section extraction and doing authentication thru that guided sections.

Can you provide more background as to why it is important to get this into edk2 as a "standard" and why it requires defining new structures and new library abstractions?

Finally a point on the policy. In many products (especially commercial products) you don't see "UEFI secure boot (PK/KEK/DB/DBX)" leveraged for trust prior to EndOfDxe. Since UEFI secure boot is often user controlled this opens up your "platform" to compromise that can be impossible to recover from.

Thanks
Sean

On 6/16/2020 10:50 AM, Mackay, Curtis A wrote:
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: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

Brian J. Johnson
 

Thanks for the link.  I agree that this change will make the StatusCodeHandler driver more modular, and is a step in the right direction.

But I think it could go further, with almost no additional work, and simplify the overall Status Code mechanism, not just the StatusCodeHandler driver.  Currently, the StatusCodeHandler driver entry routines run some initialization code, register callbacks (eg. for ExitBootServices and SetVirtualAddressMap), and call the RscHandler PPI/Protocol to register the worker routines.  If I'm understanding the proposal correctly, all that code will be moved to the individual NULL libraries, since any particular library may or may not need any of it.  Then the StatusCodeHandler modules will be left with no code of their own at all:  they will only be wrappers for the NULL libraries. Their entry routines will do nothing except return EFI_SUCCESS! (1)

It seems strange and wasteful to keep around empty modules like this.  So I'm suggesting adding the NULL libraries to the StatusCodeRouter modules instead.  They would need to export the protocol/PPI routines to the NULL libraries via a header file, so they could call them directly instead of looking up the protocol/PPI.  But that's a minor change.  Then you could remove the empty StatusCodeHandler modules entirely.  The advantage would be that there would be fewer modules in the build, simplifying the .dsc and .fdf files slightly.  It would also reduce code size a bit by sharing common library routines, such as BaseLib, with the StatusCodeRouter modules.

If those don't seem like worthwhile advantages, that's OK with me.  I don't want to belabor the point, or impede progress.  If others are OK with the proposal as it stands, then I am too.

Thanks,

*Brian J. Johnson
*Enterprise X86 Lab

Hewlett Packard Enterprise


(1) The StatusCodeHandlerRuntimeDxe driver also handles PcdStatusCodeReplayIn as part of its entry code.  That code would probably have to stay in a separate module rather than being linked to StatusCodeRouter as a NULL library.  That way it could be dispatched after the ReportStatusCode protocol is available.

------------------------------------------------------------------------
*From:* Dong, Eric [mailto:eric.dong@...]
*Sent:* Thursday, June 25, 2020, 10:41 AM
*To:* Brian J. Johnson <brian.johnson@...>, Bi, Dandan <dandan.bi@...>, Andrew Fish <afish@...>, edk2-devel-groups-io <devel@edk2.groups.io>
*Cc:* rfc@edk2.groups.io <rfc@edk2.groups.io>, Ni, Ray <ray.ni@...>, Wang, Jian J <jian.j.wang@...>, Wu, Hao A <hao.a.wu@...>, Tan, Ming <ming.tan@...>, Laszlo Ersek <lersek@...>
*Subject:* [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

Hi Brian,

In this new design, we still use register status code handler Protocol/Ppi to register the handler logic. We just want to change the StatusCodeHandler driver. We try to split the register logic to NULL library to make the code more modularity. We already created sample library in Edk2-Platforms repo https://github.com/tianocore/edk2-platforms/tree/master/Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeStatusCodeHandlerLib. You can check this code to understand more about what we want to do.

Thanks,

Eric

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

Dandan,

The Status Code Protocol/PPI is the high-level interface which is being implemented.  The ReportStatusCodeRouter module implements this in terms of the ReportStatusCodeHandler Protocol/PPI.  That allows multiple ReportStatusCodeHandler modules to be used at once, so they can each react to different types of status codes, or report them through multiple channels.  That sort of multiplexing seems like a useful feature.

Now we're considering adding a mechanism which allows registering status code handlers via NULL libraries, rather than via the protocol/PPI. That sounds like exactly what ReportStatusCodeRouter is intended for.  It wouldn't really change its scope, it would just make it more flexible.  Adding this feature via a StatusCodeHandler module wouldn't improve modularity, it would just add complexity.  As an OEM, adding a custom handler would look the same to me either way:  I would have to add the NULL class library to a MdeModulePkg driver's entry in my .dsc file.  It doesn't matter to me whether it's the ReportStatusCodeRouter or StatusCodeHandler module.  And if I can do it in ReportStatusCodeRouter, then I don't need to include any StatusCodeHandler modules in the build at all.  That saves code space and reduces the number of modules in the APRIORI list, which are both good things.

ReportStatusCodeRouterPei already has to track registered handlers in PEI when running from ROM (it uses a HOB.)  Tracking handlers from NULL libraries wouldn't be any harder.  In fact, it looks like it could just export the Register() function to the NULL libraries, and they could call it in their constructors.

I think using NULL libraries for status code handlers is a great idea.  I'd just like to take that opportunity to reduce the complexity of the overall status code stack while we're at it.

Thanks,

*Brian J. Johnson
*Enterprise X86 Lab

Hewlett Packard Enterprise

------------------------------------------------------------------------

*From:* Bi, Dandan [mailto:dandan.bi@...]

*Sent:* Monday, June 22, 2020, 2:27 AM

*To:* Andrew Fish <afish@...> <mailto:afish@...>, edk2-devel-groups-io <devel@edk2.groups.io> <mailto:devel@edk2.groups.io>, brian.johnson@... <mailto:brian.johnson@...> <brian.johnson@...> <mailto:brian.johnson@...>

*Cc:* rfc@edk2.groups.io <mailto:rfc@edk2.groups.io> <rfc@edk2.groups.io> <mailto:rfc@edk2.groups.io>, Dong, Eric <eric.dong@...> <mailto:eric.dong@...>, Ni, Ray <ray.ni@...> <mailto:ray.ni@...>, Wang, Jian J <jian.j.wang@...> <mailto:jian.j.wang@...>, Wu, Hao A <hao.a.wu@...> <mailto:hao.a.wu@...>, Tan, Ming <ming.tan@...> <mailto:ming.tan@...>, Laszlo Ersek <lersek@...> <mailto:lersek@...>, Bi, Dandan <dandan.bi@...> <mailto:dandan.bi@...>

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

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.

2. 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.

3. 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@...> <mailto:afish@...>
*Sent:* Saturday, June 20, 2020 2:04 AM
*To:* edk2-devel-groups-io <devel@edk2.groups.io>
<mailto:devel@edk2.groups.io>; brian.johnson@...
<mailto:brian.johnson@...>
*Cc:* Bi, Dandan <dandan.bi@...>
<mailto:dandan.bi@...>; rfc@edk2.groups.io
<mailto:rfc@edk2.groups.io>; Dong, Eric <eric.dong@...>
<mailto:eric.dong@...>; Ni, Ray <ray.ni@...>
<mailto:ray.ni@...>; Wang, Jian J <jian.j.wang@...>
<mailto:jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>
<mailto:hao.a.wu@...>; Tan, Ming <ming.tan@...>
<mailto:ming.tan@...>
*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@... <mailto:brian.johnson@...>wrote:

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.

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: SubRegionAuthLib RFC

Sukerkar, Amol N
 

Hi Laszlo,

Please see my comments below.

Thanks,
Amol

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Thursday, June 25, 2020 4:57 AM
To: rfc@edk2.groups.io; Mackay, Curtis A <curtis.a.mackay@...>
Cc: Kinney, Michael D <michael.d.kinney@...>; Wang, Jian J <jian.j.wang@...>; Yao, Jiewen <jiewen.yao@...>; Sukerkar, Amol N <amol.n.sukerkar@...>; Agrawal, Sachin <sachin.agrawal@...>
Subject: Re: [edk2-rfc] SubRegionAuthLib RFC

Hi,

On 06/19/20 18:55, Mackay, Curtis A wrote:
Friendly reminder to review and provide feedback on the RFC. We are looking to target a WW34 deadline with this design.
I don't have a stake in this feature, but because the presentation isn't long, I've briefly skimmed it:

- It's unclear whether the public data structures describe a wire format. If they do, they should be packed, IMO.
[ANS] We tries to follow the precedence in other EDK2 implementation. Any suggestions to improve are welcome.

- The struct hack (SUB_REGION_VERIFICATION.CertData being an array with
1 element) is not ideal, in my opinion. Especially because SUB_REGION_VERIFICATION is embedded in EFI_SUB_REGION_AUTHENTICATION afterwards. Personally I prefer comments to the struct hack that explain where the CertData starts. Out-of-bounds subscripts for CertData -- having just one element -- are dubious; we shouldn't have more of that (IMO).
[ANS] You can ignore SIGNED_SUB_REGION for now. The only intention here is to show that EFI_SUB_REGION_AUTHENTICATION is the header (with signature) and void *blob is the payload. So, even if you consider SUB_REGION_VERIFICATION as a member of EFI_SUB_REGION_AUTHENTICATION struct, CertData is still at the bottom of the struct stack. And depending on the type of signature the size will vary. But due to the nature of signature as PKCS#7, openssl API will be able to parse it. How do you propose we improve the struct?

- it's unclear whether EFI_SUB_REGION_AUTHENTICATION.Name is supposed to be NUL-terminated, or not.
[ANS] Name is stored in a bounded array. It uses memcmp to validate which is limited to MAX_NAME bytes. If it exceeds and corrupts VendorGuid, the authentication will fail since VendorGuid is part of data over which signature is calculated.

- "char" is not a good element type for
EFI_SUB_REGION_AUTHENTICATION.Name. If we want it to be "text", then it should either be CHAR8 or CHAR16. If we want it to be any binary string, then it should be UINT8.
[ANS] Agree.

- the EFI_ prefix is used inconsistently on the type names (not sure if that's intentional -- I can't tell the principle behind the current use)
[ANS] Could you suggest how we can make it compliant here?

- in SIGNED_SUB_REGION, the field names are not aligned with each other, and edk2 uses VOID spelling rather than "void". Also "blob" should be CamelCased as "Blob".
[ANS] Agree. Needs to change.

- The size of the entire region is not encoded (in a generic way,
anyway) in the structures. Is this intentional perhaps?
[ANS] SUB_REGION_HEADER.Length = sizeof(SUB_REGION_HEADER) + sizeof (CertData). Do you think anything else needs to be done?


- in the AuthenticateSubRegion() prototype, SignedSubRegionSize has type UINTN, but (*SubRegionDataSize) has type UINT32. I think these types should be the same.
[ANS] Agree. Needs to change.

- same for SignedSubRegionImage and (*SubRegionDataBuffer): (UINT8*) vs.
(VOID*)
[ANS] Agree.

- the ownership of the output (*SubRegionDataBuffer) is unclear. Is it a pointer into the input buffer? Is it a copy, allocated dynamically?
[ANS] it is a pointer to original sub-region data (without signature header). If authentication is unsuccessful, it will be NULL. But, I agree AuthenticateSubRegion should just authenticate the sub-region. Parsing the data should be left to the caller.


I have no higher-level comments (i.e. on the intended use case).

Thanks
Laszlo


From: Mackay, Curtis A
Sent: Tuesday, June 16, 2020 10:51 AM
To: 'rfc@edk2.groups.io' <rfc@edk2.groups.io>
Cc: Kinney, Michael D <michael.d.kinney@...>; Wang, Jian J
<jian.j.wang@...>; Yao, Jiewen <jiewen.yao@...>; Sukerkar,
Amol N <amol.n.sukerkar@...>; Agrawal, Sachin
<sachin.agrawal@...>
Subject: SubRegionAuthLib RFC

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: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

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

Hi Brian,

In this new design, we still use register status code handler Protocol/Ppi to register the handler logic. We just want to change the StatusCodeHandler driver. We try to split the register logic to NULL library to make the code more modularity. We already created sample library in Edk2-Platforms repo https://github.com/tianocore/edk2-platforms/tree/master/Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeStatusCodeHandlerLib. You can check this code to understand more about what we want to do.

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

Dandan,

The Status Code Protocol/PPI is the high-level interface which is being implemented. The ReportStatusCodeRouter module implements this in terms of the ReportStatusCodeHandler Protocol/PPI. That allows multiple ReportStatusCodeHandler modules to be used at once, so they can each react to different types of status codes, or report them through multiple channels. That sort of multiplexing seems like a useful feature.

Now we're considering adding a mechanism which allows registering status code handlers via NULL libraries, rather than via the protocol/PPI. That sounds like exactly what ReportStatusCodeRouter is intended for. It wouldn't really change its scope, it would just make it more flexible. Adding this feature via a StatusCodeHandler module wouldn't improve modularity, it would just add complexity. As an OEM, adding a custom handler would look the same to me either way: I would have to add the NULL class library to a MdeModulePkg driver's entry in my .dsc file. It doesn't matter to me whether it's the ReportStatusCodeRouter or StatusCodeHandler module. And if I can do it in ReportStatusCodeRouter, then I don't need to include any StatusCodeHandler modules in the build at all. That saves code space and reduces the number of modules in the APRIORI list, which are both good things.

ReportStatusCodeRouterPei already has to track registered handlers in PEI when running from ROM (it uses a HOB.) Tracking handlers from NULL libraries wouldn't be any harder. In fact, it looks like it could just export the Register() function to the NULL libraries, and they could call it in their constructors.

I think using NULL libraries for status code handlers is a great idea. I'd just like to take that opportunity to reduce the complexity of the overall status code stack while we're at it.

Thanks,

Brian J. Johnson
Enterprise X86 Lab

Hewlett Packard Enterprise

________________________________
From: Bi, Dandan [mailto:dandan.bi@...]
Sent: Monday, June 22, 2020, 2:27 AM
To: Andrew Fish <afish@...><mailto:afish@...>, edk2-devel-groups-io <devel@edk2.groups.io><mailto:devel@edk2.groups.io>, brian.johnson@...<mailto:brian.johnson@...> <brian.johnson@...><mailto:brian.johnson@...>
Cc: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io> <rfc@edk2.groups.io><mailto:rfc@edk2.groups.io>, Dong, Eric <eric.dong@...><mailto:eric.dong@...>, Ni, Ray <ray.ni@...><mailto:ray.ni@...>, Wang, Jian J <jian.j.wang@...><mailto:jian.j.wang@...>, Wu, Hao A <hao.a.wu@...><mailto:hao.a.wu@...>, Tan, Ming <ming.tan@...><mailto:ming.tan@...>, Laszlo Ersek <lersek@...><mailto:lersek@...>, Bi, Dandan <dandan.bi@...><mailto:dandan.bi@...>
Subject: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

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@...><mailto:afish@...>
Sent: Saturday, June 20, 2020 2:04 AM
To: edk2-devel-groups-io <devel@edk2.groups.io><mailto:devel@edk2.groups.io>; brian.johnson@...<mailto:brian.johnson@...>
Cc: Bi, Dandan <dandan.bi@...><mailto:dandan.bi@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; Dong, Eric <eric.dong@...><mailto:eric.dong@...>; Ni, Ray <ray.ni@...><mailto:ray.ni@...>; Wang, Jian J <jian.j.wang@...><mailto:jian.j.wang@...>; Wu, Hao A <hao.a.wu@...><mailto:hao.a.wu@...>; Tan, Ming <ming.tan@...><mailto:ming.tan@...>
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@...<mailto:brian.johnson@...>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: SubRegionAuthLib RFC

Laszlo Ersek
 

Hi,

On 06/19/20 18:55, Mackay, Curtis A wrote:
Friendly reminder to review and provide feedback on the RFC. We are looking to target a WW34 deadline with this design.
I don't have a stake in this feature, but because the presentation isn't
long, I've briefly skimmed it:

- It's unclear whether the public data structures describe a wire
format. If they do, they should be packed, IMO.

- The struct hack (SUB_REGION_VERIFICATION.CertData being an array with
1 element) is not ideal, in my opinion. Especially because
SUB_REGION_VERIFICATION is embedded in EFI_SUB_REGION_AUTHENTICATION
afterwards. Personally I prefer comments to the struct hack that explain
where the CertData starts. Out-of-bounds subscripts for CertData --
having just one element -- are dubious; we shouldn't have more of that
(IMO).

- it's unclear whether EFI_SUB_REGION_AUTHENTICATION.Name is supposed to
be NUL-terminated, or not.

- "char" is not a good element type for
EFI_SUB_REGION_AUTHENTICATION.Name. If we want it to be "text", then it
should either be CHAR8 or CHAR16. If we want it to be any binary string,
then it should be UINT8.

- the EFI_ prefix is used inconsistently on the type names (not sure if
that's intentional -- I can't tell the principle behind the current use)

- in SIGNED_SUB_REGION, the field names are not aligned with each other,
and edk2 uses VOID spelling rather than "void". Also "blob" should be
CamelCased as "Blob".

- The size of the entire region is not encoded (in a generic way,
anyway) in the structures. Is this intentional perhaps?


- in the AuthenticateSubRegion() prototype, SignedSubRegionSize has type
UINTN, but (*SubRegionDataSize) has type UINT32. I think these types
should be the same.

- same for SignedSubRegionImage and (*SubRegionDataBuffer): (UINT8*) vs.
(VOID*)

- the ownership of the output (*SubRegionDataBuffer) is unclear. Is it a
pointer into the input buffer? Is it a copy, allocated dynamically?


I have no higher-level comments (i.e. on the intended use case).

Thanks
Laszlo


From: Mackay, Curtis A
Sent: Tuesday, June 16, 2020 10:51 AM
To: 'rfc@edk2.groups.io' <rfc@edk2.groups.io>
Cc: Kinney, Michael D <michael.d.kinney@...>; Wang, Jian J <jian.j.wang@...>; Yao, Jiewen <jiewen.yao@...>; Sukerkar, Amol N <amol.n.sukerkar@...>; Agrawal, Sachin <sachin.agrawal@...>
Subject: SubRegionAuthLib RFC

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: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

Brian J. Johnson
 

Dandan,

The Status Code Protocol/PPI is the high-level interface which is being implemented.  The ReportStatusCodeRouter module implements this in terms of the ReportStatusCodeHandler Protocol/PPI.  That allows multiple ReportStatusCodeHandler modules to be used at once, so they can each react to different types of status codes, or report them through multiple channels.  That sort of multiplexing seems like a useful feature.

Now we're considering adding a mechanism which allows registering status code handlers via NULL libraries, rather than via the protocol/PPI.  That sounds like exactly what ReportStatusCodeRouter is intended for.  It wouldn't really change its scope, it would just make it more flexible.  Adding this feature via a StatusCodeHandler module wouldn't improve modularity, it would just add complexity.  As an OEM, adding a custom handler would look the same to me either way:  I would have to add the NULL class library to a MdeModulePkg driver's entry in my .dsc file.  It doesn't matter to me whether it's the ReportStatusCodeRouter or StatusCodeHandler module.  And if I can do it in ReportStatusCodeRouter, then I don't need to include any StatusCodeHandler modules in the build at all.  That saves code space and reduces the number of modules in the APRIORI list, which are both good things.

ReportStatusCodeRouterPei already has to track registered handlers in PEI when running from ROM (it uses a HOB.)  Tracking handlers from NULL libraries wouldn't be any harder.  In fact, it looks like it could just export the Register() function to the NULL libraries, and they could call it in their constructors.

I think using NULL libraries for status code handlers is a great idea.  I'd just like to take that opportunity to reduce the complexity of the overall status code stack while we're at it.

Thanks,

*Brian J. Johnson
*Enterprise X86 Lab

Hewlett Packard Enterprise

------------------------------------------------------------------------
*From:* Bi, Dandan [mailto:dandan.bi@...]
*Sent:* Monday, June 22, 2020, 2:27 AM
*To:* Andrew Fish <afish@...>, edk2-devel-groups-io <devel@edk2.groups.io>, brian.johnson@... <brian.johnson@...>
*Cc:* rfc@edk2.groups.io <rfc@edk2.groups.io>, Dong, Eric <eric.dong@...>, Ni, Ray <ray.ni@...>, Wang, Jian J <jian.j.wang@...>, Wu, Hao A <hao.a.wu@...>, Tan, Ming <ming.tan@...>, Laszlo Ersek <lersek@...>, Bi, Dandan <dandan.bi@...>
*Subject:* [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

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.

2. 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.

3. 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@...>
*Sent:* Saturday, June 20, 2020 2:04 AM
*To:* edk2-devel-groups-io <devel@edk2.groups.io>; brian.johnson@...
*Cc:* Bi, Dandan <dandan.bi@...>; rfc@edk2.groups.io; Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Tan, Ming <ming.tan@...>
*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@... <mailto:brian.johnson@...>wrote:

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.

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: SubRegionAuthLib RFC

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

Friendly reminder to review and provide feedback on the RFC. We are looking to target a WW34 deadline with this design.

 

Best,

Curtis

 

From: Mackay, Curtis A
Sent: Tuesday, June 16, 2020 10:51 AM
To: 'rfc@edk2.groups.io' <rfc@edk2.groups.io>
Cc: Kinney, Michael D <michael.d.kinney@...>; Wang, Jian J <jian.j.wang@...>; Yao, Jiewen <jiewen.yao@...>; Sukerkar, Amol N <amol.n.sukerkar@...>; Agrawal, Sachin <sachin.agrawal@...>
Subject: SubRegionAuthLib RFC

 

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


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@...>;
devel@edk2.groups.io
Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; Wang,
Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Tan,
Ming <ming.tan@...>
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@...>
Sent: Saturday, June 20, 2020 2:04 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>; brian.johnson@...
Cc: Bi, Dandan <dandan.bi@...>; rfc@edk2.groups.io; Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Tan, Ming <ming.tan@...>
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@...<mailto:brian.johnson@...>> 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@...>;
devel@edk2.groups.io
Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; Wang,
Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Tan,
Ming <ming.tan@...>
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@...>; rfc@edk2.groups.io
Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Tan, Ming <ming.tan@...>
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@...> 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@...>; ray.ni@...; leif@...;
devel@edk2.groups.io
Cc: Felixp@...; Doran, Mark <mark.doran@...>; Andrew Fish
<afish@...>; Laszlo Ersek <lersek@...>; Kinney, Michael D
<michael.d.kinney@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@...>
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@...; leif@...;
devel@edk2.groups.io
Cc: Felixp@...; Doran, Mark <mark.doran@...>; Andrew Fish
<afish@...>; Laszlo Ersek <lersek@...>; Kinney, Michael D
<michael.d.kinney@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@...>
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@...; devel@edk2.groups.io
Cc: Felixp@...; Doran, Mark <mark.doran@...>; Andrew Fish
<afish@...>; Laszlo Ersek <lersek@...>; Kinney, Michael
D <michael.d.kinney@...>
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@...>

- Bret

From: Bret Barkelew<mailto:Bret.Barkelew@...>
Sent: Wednesday, May 27, 2020 10:45 AM
To: Rebecca Cran<mailto:rebecca@...>; rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Andrew Fish<mailto:afish@...>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@...<mailto:spbrogan@...>; Desimone, Nathaniel L<mailto:nathaniel.l.desimone@...>; Kinney, Michael D<mailto:michael.d.kinney@...>; Leif Lindholm (Nuvia address)<mailto:leif@...>
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@...>
Sent: Wednesday, May 27, 2020 9:07 AM
To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; lersek@...<mailto:lersek@...>; Bret Barkelew<mailto:Bret.Barkelew@...>; Andrew Fish<mailto:afish@...>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; spbrogan@...<mailto:spbrogan@...>; Desimone, Nathaniel L<mailto:nathaniel.l.desimone@...>; Kinney, Michael D<mailto:michael.d.kinney@...>; Leif Lindholm (Nuvia address)<mailto:leif@...>
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

421 - 440 of 786