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 8:
(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 */
As far as we are concerned it is a crypto library for use in coreboot.
For crypto primitives, that is correct. So I am okay with you using functions like vb2_digest_buffer() and assume those (or equivalents that we could easily patch into your code for you) will always stay available, because the format of a raw SHA256 hash will never change. (Whether RSA primitives like vb2_rsa_verify_digest() also belong to that is an open question... nobody has needed those outside the normal vboot paths yet, but I guess we could allow that if necessary.) But anything above that, our keyblocks, preambles and the workbuffer, are custom to our specific verification solution and therefore subject to change as we develop it forward. We do not want you to call any interfaces involving those (e.g. vb2api_verify_kernel_data()) because that makes it hard for us to change those interfaces later. They were not meant as a toolbox with APIs set in stone.
However there is one are that is not covered and that is signature verification, and the related key import. We have no problems to provide a key with a vboot wrapper but we would like to be able to verify the signature of a random datablock. Basically this has nothing to do with vboot itself. The datablock may not even be included in coreboot image. This can be e.g. an FPGA image that we need to program.
Well... yeah, okay, we don't have a solution we can offer you there. The kernel verification parts of vboot are not really in a good state right now due to a decade of built up cruft and we can't just freeze everything the way it looks right now to support your use case. We have somewhat vague ideas of eventually bringing kernel verification into coreboot but that's still going to be years out.
I don't really see anything you're doing here doing anything like that though? The code you have here just verifies firmware parts (coreboot stages, oproms, etc.), so why do you need an intermediate signature? You can just use the normal vboot verification which automatically covers the CBFS stuff already, and for anything else (e.g. oproms) you want to chain you can just put their hash in the CBFS. You'd do a firmware update when you update those anyway.
If you actually want to do kernel verification you'd do that from a payload (not directly from coreboot) anyway, and there you could link whatever frozen version of vboot you want.