Re: SubRegionAuthLib RFC
Mackay, Curtis A <curtis.a.mackay@...>
Hi Sean,toggle quoted messageShow quoted text
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.
From: Sean Brogan <firstname.lastname@example.org>
Sent: Thursday, June 25, 2020 4:41 PM
To: email@example.com; Mackay, Curtis A <firstname.lastname@example.org>
Cc: Kinney, Michael D <email@example.com>; Wang, Jian J <firstname.lastname@example.org>; Yao, Jiewen <email@example.com>; Sukerkar, Amol N <firstname.lastname@example.org>; Agrawal, Sachin <email@example.com>
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: