Attention is currently required from: Erik van den Bogaert, Felix Singer, Michał Żygowski, Frans Hendriks, Paul Menzel, Arthur Heymans, Wim Vervoorn. Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/52025 )
Change subject: vc/eltan/security/verified_boot/vboot_check.c: Add cbfs_map_compressed() ......................................................................
Patch Set 4:
(1 comment)
Patchset:
PS3:
Changing behavoir of functions might result in building binaries, but not garanty run-time functionality.
Exactly, that's the problem. The point of vendorcode is that you can put isolated pieces of code in there that don't really interact much with the rest of coreboot, so that vendors can implement their own isolated features that don't need to pass such a strict review process and community consensus as core coreboot patches, because they're out of the way and don't bother anyone else. But your feature here is anything but isolated: it makes deep assumptions about implementation details of CBFS (and vboot) and it's almost impossible for someone else to make changes to CBFS code without accidentally breaking your stuff. This is not maintainable. And we can't have a system where every vendor submits their own vendorcode that has all these deep dependencies on some core coreboot framework, then nobody could do any coreboot development at all anymore because you always risk breaking some vendor's special stuff. That's not what vendorcode was meant for.
You point to CONFIG_CBFS_VERIFICATION, but the help mentioned work in progress. Do not use (yet).
Right, I've just updated the description of CONFIG_CBFS_VERIFICATION a few days ago, it should be ready for use now. See CB:59982.
Does VBOOT contain function to hash unconpressed CBFS part?
So... CBFS verification will hash every file. For compressed files it will hash the compressed data and then check that hash before the file gets decompressed. With CBFS verification every file is directly tied to the bootblock, so you can't update individual files without updating the whole CBFS.
vboot splits CBFS into two areas (RO and RW). The whole RW area is hashed and signed (so not individual files one by one, but just the whole thing in one go). The public keys used to check that area are stored in the RO part. vboot is designed to be used with SPI flash write protection where the whole RO part is permanently write protected, and the RW part can be updated in the field. (Eventually the goal is to tie CBFS verification and vboot together, so that files in the RW area are also hashed individually and can be verified one at a time. That part isn't done yet. That is just an optimization, though... security-wise, the current version where the whole section is verified at once is just as secure.)
If you can tell me what kind of verification exactly you need (e.g. where is your root of trust, how do you protect it, how do you do updates, etc.) I can help you figure out which combination of these can work for your use case.