summaryrefslogtreecommitdiff
path: root/src/include/cbfs_glue.h
AgeCommit message (Collapse)Author
2021-04-06include/cbfsglue.h: Use BIOS_INFO for LOG macroWim Vervoorn
The ERROR() and LOG() macros both used BIOS_ERR as the error level. The messages generated by the LOG() macro are informational items. Change to BIOS_INFO to reflect that. BUG=N/A TEST=tested on facebook monolith Change-Id: I3827a7d65a9d70045a36fb8db4b2c129e1045122 Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/52019 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2020-12-03cbfs: Add verification for RO CBFS metadata hashJulius Werner
This patch adds the first stage of the new CONFIG_CBFS_VERIFICATION feature. It's not useful to end-users in this stage so it cannot be selected in menuconfig (and should not be used other than for development) yet. With this patch coreboot can verify the metadata hash of the RO CBFS when it starts booting, but it does not verify individual files yet. Likewise, verifying RW CBFSes with vboot is not yet supported. Verification is bootstrapped from a "metadata hash anchor" structure that is embedded in the bootblock code and marked by a unique magic number. This anchor contains both the CBFS metadata hash and a separate hash for the FMAP which is required to find the primary CBFS. Both are verified on first use in the bootblock (and halt the system on failure). The CONFIG_TOCTOU_SAFETY option is also added for illustrative purposes to show some paths that need to be different when full protection against TOCTOU (time-of-check vs. time-of-use) attacks is desired. For normal verification it is sufficient to check the FMAP and the CBFS metadata hash only once in the bootblock -- for TOCTOU verification we do the same, but we need to be extra careful that we do not re-read the FMAP or any CBFS metadata in later stages. This is mostly achieved by depending on the CBFS metadata cache and FMAP cache features, but we allow for one edge case in case the RW CBFS metadata cache overflows (which may happen during an RW update and could otherwise no longer be fixed because mcache size is defined by RO code). This code is added to demonstrate design intent but won't really matter until RW CBFS verification can be supported. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I8930434de55eb938b042fdada9aa90218c0b5a34 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41120 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2020-10-30cbfs: Hook up to new CBFS implementationJulius Werner
This patch hooks coreboot up to the new commonlib/bsd CBFS implementation. This is intended as the "minimum viable patch" that makes the new implementation useable with the smallest amount of changes -- that is why some of this may look a bit roundabout (returning the whole metadata for a file but then just using that to fill out the rdevs of the existing struct cbfsf). Future changes will migrate the higher level CBFS APIs one-by-one to use the new implementation directly (rather than translated into the results of the old one), at which point this will become more efficient. Change-Id: I4d112d1239475920de2d872dac179c245275038d Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38422 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>