Change in coreboot[master]: vc/eltan/security/verified_boot/vboot_check.c: Add cbfs_map_compressed()

[Julius Werner (Code Review)]

Attention is currently required from: Felix Singer, Michał Żygowski, Frans Hendriks, 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 3:

(1 comment)

Patchset:

PS3: 
Sorry, but you're just... breaking every assumption of how CBFS is supposed to be used with this. cbfs_map() does actually work on compressed files if your platform provides a _cbfs_cache, but it then provides you a pointer to the uncompressed data and that's not what you're looking for here, right? You're trying to get at the raw compressed data, and that just doesn't make sense in a system where compression is supposed to be transparent. This whole concept of you trying to stash something as invasive as a verification system away in vendorcode just doesn't really work out.

Haven't we talked about this before (specifically regarding prog_locate_hook())? I thought you guys had already said years ago that you were moving away from that and we could eventually deprecate it? What ever happened to that?

Can you not just use CONFIG_CBFS_VERIFICATION and CONFIG_TPM_MEASURED_BOOT? What high-level use cases are you trying to solve that are not covered by that?

I mean you can submit this patch and call a bunch of internal functions from your code private vendorcode that were not supposed to leave the CBFS core, breaking every abstraction we have... but sooner or later that will break again (in fact it's already broken again and this patch should no longer apply as written on ToT today), and then somebody who was just trying to update supposedly internal parts of the CBFS framework has to poke around here in this stuff that doesn't fit with any of the rest of coreboot and try to do your maintenance work (or they'll just accidentally break you because they don't understand the totally unintended ways in which you're using APIs, like I did in CB:39304). It's just not a long-term viable development approach. Complicated and invasive things like verification and measurement need to be implemented once, in the central framework, in a way that covers everyone's use cases... not a dozen times individually by each vendor. (Same goes for whatever you're doing with the vboot APIs here, btw, that's not how they're supposed to be used and it *will break* sooner or later.)

*Please* move your platforms onto the common frameworks. If you have use cases not covered by them, please come talk to us and we can try to find a solution. If you just keep doing your own thing somewhere that nobody else is looking at, it will keep breaking and eventually it will probably need to be removed for being a maintenance burden.