Re: SubRegionAuthLib RFC


Thanks for the info.

I would like to break my continued comments into two distinct parts.

1. Still interested in why we need new abstractions for the data blob. From your use case i would suggest leveraging something like a signed section. if that is used then the PI spec already has most of the abstractions defined, edk2 has tool infrastructure already, and edk2 core services already have a "plugin" model defined. I would be curious to understand why building new would be better.

2. On the key management/authentication management. When you say a "3rd party needs to be able to add their own public keys to bios". Is that something the IHV works with bios author or is that IHV works with user and user adds the key? Just trying to understand if this is a B2B model or business to end user model. Secondly, i think there are some leanings and challenges from PK/KEK/DB/DBX model that should be incorporated in any new design. I am also curious if and how this impacts measured boot/TPM pcr values, etc.


On 7/2/2020 11:17 AM, Mackay, Curtis A wrote:
Hi Sean,
The binary to be signed is a blob of data to be consumed by BIOS. In the example mentioned the signed blob is packaged in an FV, but the solution should be flexible to work with other firmware management blocks.
The target use case is that the blob may be generated and signed by a 3rd party downstream of the ODM/OEM. The 3rd party needs to be able to add their own public keys to BIOS to allow BIOS to verify their blob.
After some discussion with others CC'd, the design is trending to use a separate set of variables that are reserved for data, similar to UEFI secure boot's PK/KEK/DB/DBX. This will limit the threat of attack on these keys, as only the data blobs would be compromised in the case of a compromised key, instead of all UEFI secure boot being compromised.
-----Original Message-----
From: Sean Brogan <spbrogan@...>
Sent: Thursday, June 25, 2020 4:41 PM
To:; Mackay, Curtis A <curtis.a.mackay@...>
Cc: Kinney, Michael D <michael.d.kinney@...>; Wang, Jian J <>; Yao, Jiewen <jiewen.yao@...>; Sukerkar, Amol N <amol.n.sukerkar@...>; Agrawal, Sachin <sachin.agrawal@...>
Subject: Re: [edk2-rfc] SubRegionAuthLib RFC
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.
On 6/16/2020 10:50 AM, Mackay, Curtis A wrote:

I filed a proposal for a new library to handle UEFI BIOS sub-regions at 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

Join to automatically receive all group messages.