Julius Werner 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 */
Understood, the issue is that we need to have the code for this project upstreamed.
Can you explain why? I assume you are not planning to ship firmware updates from ToT coreboot forever? I think most companies cut a stabilization branch for their products at some point anyway to decrease maintenance effort and risk for future updates.
Basically what we need to have is a way to add a public key to the workbuffer so this can be used for the signature verification. I haven't really found a public API to do this. Do you have suggestion? Or alternatively is it possible to make the api to do this public?
Can you describe in more high level what goals you're trying to achieve (e.g. what you need integrity checked or measured and why)? In general our goal with the vboot/coreboot integration is to eventually support enough options to cover everyone's high-level needs, and if your situation really has a useful use case that the existing solution cannot cover we can talk about how to add it. But we basically already support full measurement and integrity checking of the firmware, and I don't really understand what your solution is achieving that is different from that. The inner workings of vboot and the work buffer, how exactly keys are handled and what is signed by what are supposed to be implementation details. We want to make sure that the solution overall covers the use cases people have, but we don't want everyone to design their own key ladder and support all possible different ways to plug crypto primitives together (because that wouldn't be maintainable).