Wim Vervoorn has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38590 )
Change subject: vendorcode/eltan/security: Switch to vb2 vboot library ......................................................................
Patch Set 6:
(1 comment)
https://review.coreboot.org/c/coreboot/+/38590/2/src/vendorcode/eltan/securi... File src/vendorcode/eltan/security/verified_boot/vboot_check.c:
https://review.coreboot.org/c/coreboot/+/38590/2/src/vendorcode/eltan/securi... PS2, Line 17: #define NEED_VB20_INTERNALS /* Peeking into vb2_shared_data */
Julius has made some good points here. […]
Let me explain what we are trying to do at a high level. What this does is provide a simple verified boot solution for systems that don't have a TPM (I know that for this specific system a TPM is available but that is not relevant for the verified boot solution).
This verified boot solution depends on the bootblock being read-only while the remainder of the can be reflashed. The verification relies on a manifest containing SHA-256 hashes of the components that need to be verified. This manifest is in the RW portion of the flash.
The manifest is signed so its integrity can be verified. The public key used for this verification is contained in the RO area as well.
At this point in time we can do everything we need using the public API except preparing an environment that can be used to perform the verification of the manifest. As you can see in the code we can use the vb2api_verify_kernel_data for the verification.
The issue we still have is to find a proper way to setup the environment to actually perform this verification. The api that is available to do this totally relies on the vboot implementation and implements the steps required for this. That is not what we need in this case.
So looking at the functionality the ideal solution for us would be to have a way to import a key into the environment and to have the possibility to verify the signature of a custom datablock (the manifest in our case). The call to verify would be very similar to what's in the vb2api_verify_kernel_data at this moment except that it is not tied to the kernel.
I have marked the issue as resolved so it's possible for this patch to proceed but we can still continue this discussion and find a way to come to a workable solution for all of us.
Personally I don't think that adding the possibility to perform a signature verification on a custom data block would compromise the integrity of your solution in any way or make it less maintaineable.