ap_ro_verification: add implementation of the new scheme

The new AP RO verification approach, version 2, places the AP RO
verification structures in the AP RO itself, as described below.

A new section is included in AP RO FMAP, called RO_GSCVD, which
contains all information necessary to verify the AP RO:
gsc_verification_data (GVD) structure, GVD signature, the platform key
to verify the signature and the root key to verify the platform key.

GVD contains an array of AP RO ranges to be verified and the hash of
the contents of those ranges.

The signature of the GVD is followed by the public platform key, which
allows to verify the GVD signature.

The platform key in turn is signed by the root key, and the public
root key is also present in RO_GSCVD, this allows to validate the
platform key.

The hash of the public root key is hardcoded in the GSC firmware, this
gives the GSC the ability to verify the chain of objects in the
RO_GSCVD FMAP area starting with the root key.

This implementation supports both old and new AP RO verification
schemes as follows. The structure describing data saved in the
dedicated GSC flash page has been enhanced to support both old and new
AP RO verification schemes. To maintain backwards compatibility the 16
bit header field version is converted into two byte fields, version
and type. The new version is 1 and the new verification scheme type is
1, the old verification scheme type value is set to zero.

If a V1 structure is found in the H1 hash page, but verification
fails, a V2 verification is attempted just in case the RO was
reprogrammed and now includes RO_GSCVD area in FMAP.

The hash of the root key is saved in the text section named
.rodata.root_key_hash.

As presented, tests/devkeys/kernel_subkey.vbpubk from the
vboot_reference tree is used as the root key. The label of the section
where the hash is stored will allow the signer to replace the test key
hash with the prod root key hash.

Verification process is moved to the TPM task context to satisfy the
increased stack requirements of V2 calculations. This provides an
additional benefit: verification can be triggered by the AP issuing
the vendor command.

A CCD capability will be added in a follow up CL to restrict
conditions when the AP can invoke verification.

BUG=b:199904580

TEST=prepared an AP RO image containing RO_GSCVD and verified that the
     AP RO can be verified, and that the local cache of the GVD is
     successfully stored and allows to speed up verification.

     Experiments have shown that verifying the entire chain starting
     with the root key take 670 ms. Verifying of approximately 70KB of
     AP RO takes 200 ms.

     Verified that V1 AP RO verification is still working as expected,
     and that V2 can take over in case the AP RO was updated with an
     RO_GSCVD image, and the V1 check does not pass any more.

Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Change-Id: I1397376cd0394888da2cda16c0126a313f07d426
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3172256
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Vadim Sukhomlinov <sukhomlinov@chromium.org>

1 files changed, 4 insertions, 0 deletions

diff --git a/core/cortex-m/ec.lds.S b/core/cortex-m/ec.lds.S
index d8bb0f545e..b85ad692b8 100644
--- a/core/cortex-m/ec.lds.S
+++ b/core/cortex-m/ec.lds.S
@@ -112,6 +112,10 @@ SECTIONS
 		KEEP(*(.rodata.fips))
 		__fips_module_end = .;
 		. = ALIGN(4);
+		__ap_ro_root_key_hash_start = . ;
+		*(.rodata.root_key_hash)
+		__ap_ro_root_key_hash_end = . ;
+		. = ALIGN(4);
 		STRINGIFY(OUTDIR/core/CORE/init.o) (.text)
 #if defined(CHIP_FAMILY_NPCX7) && !defined(CONFIG_HIBERNATE_PSL)
 		/* Keep hibernate utility in last code ram block */