CONFIG_VBOOT enables vboot, the verified boot scheme. The issue here is the submodule, which is drawn in through CONFIG_VBOOT_LIB.
Why is this an issue? CONFIG_VBOOT_LIB isn't set either! Furthermore it is pretty clear to me that if CONFIG_VBOOT is not set, then no vboot related code should be generated (that also includes code ifdef guarded by CONFIG_VBOOT_LIB).
The real problem here is, because of the poor code quality of vboot integration, it doesn't matter what you have in Kconfig, you cannot compile coreboot without the vboot submodule.
That is the actual issue that needs to be addressed.
CBFS hashing (which has nothing to do with verified boot right now, although that could change).
If that's true, then why does cbfs_private.h include vb2_sha.h header at all? Let's just remove vboot dependency altogether, problem solved (see below).
that doesn't solve the problem that cbfstool has its own CBFS implementation (so it also needs to be ifguarded that way, which is a bit annoying because util/* doesn't use Kconfig at this time)
Which could be simply solved by adding something like this to the Makefile (but see below):
ifneq ($(wildcard ../3rdparty/vboot/*),) CFLAGS += -DCONFIG_VBOOT_LIB endif
That's it! You're making this a lot more complicated than actually is. Don't overcomplicate things, look for the simplest solution!
I'd even accept a local hash implementation.
Big plus one to this!
An sha checksum code is pretty small (an sha265 implementation being ca. 50-60 SLoC, no more). And it *does not need* any maintenance (if it provides the correct results for the test vectors, there's no reason to modify it, ever). It is pretty obvious that it's a lot more complicated to maintain vboot integration than having a dependency-free cbfstool.
I'm staring to have a feeling this isn't a technical issue but a political one, which I don't want to participate in. There are simple and easy solutions. I've recommended some, take it or leave it, but I'm out.
Have a nice day bzt
On 11/18/20, Patrick Georgi via coreboot coreboot@coreboot.org wrote:
Am Mi., 18. Nov. 2020 um 22:03 Uhr schrieb Nico Huber nico.h@gmx.de:
The vboot dependency has been a PITA for a while. I'll happily accept patches that make it less of a pain even if that means a little more maintenance effort. I'd even accept a local hash implementation.
That's an option. That isn't what was proposed though. The proposal was "I don't need this, it annoys me, let's drop it".
But I wonder, if that were a policy, would vboot have
such implementations? I'm sure they weren't the first. Maybe there were even concerns about external code?
Suitable license (rules out everything GNU for GPL3+, OpenSSL + offspring for their advertising clause or tomcrypt for not having a license), somewhat recently maintained (rules out libtomcrypt and SPARK crypto), suitable for embedded purposes (rules out Java implementations). Exactly the issues coreboot would face when selecting an implementation to copy. Just that by the time coreboot had to consider hashing data, vboot existed, it ticked the right boxes, and some people with overlap to coreboot were familiar with it.
Patrick
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado