GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

cbfs: Enable CBFS verification Kconfigs 

With the elimination of remaining non-verifying CBFS APIs in CB:59682,
CBFS verification is now ready to be used in its simplest form, so
enable the respective Kconfig options in menuconfig. Add a few more
restrictions to the TOCTOU_SAFETY option for problems that haven't been
solved yet, and transform a comment in cbfs.c into a die() to make sure
we don't accidentally forget implementing it once vboot integration gets
added.

Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ifeba5c962c943856ab79bc6c4cb90a60c1de4a60
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59982
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
This commit is contained in:
Julius Werner 2021-12-08 10:04:25 -08:00 committed by Felix Held
parent 20ad36547e
commit 25096eb950
2 changed files with 33 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
src/lib/Kconfig.cbfs_verification
View File

@ -2,33 +2,41 @@
# #
# This file is sourced from src/security/Kconfig for menuconfig convenience. # This file is sourced from src/security/Kconfig for menuconfig convenience.
#menu "CBFS verification" # TODO: enable once it works menu "CBFS verification"
config CBFS_VERIFICATION config CBFS_VERIFICATION
bool # TODO: make user selectable once it works bool "Enable CBFS verification"
depends on !VBOOT_STARTS_BEFORE_BOOTBLOCK # this is gonna get tricky... depends on !VBOOT_STARTS_BEFORE_BOOTBLOCK # this is gonna get tricky...
select VBOOT_LIB select VBOOT_LIB
help help
Work in progress. Do not use (yet). Say yes here to enable code that cryptographically verifies each CBFS
file as it gets loaded by chaining it to a trust anchor that is
embedded in the bootblock. This only makes sense if you use some
out-of-band mechanism to guarantee the integrity of the bootblock
itself, such as Intel BootGuard or flash write-protection.
If a CBFS image was created with this option enabled, cbfstool will
automatically update the hash embedded in the bootblock whenever it
modifies the CBFS.
if CBFS_VERIFICATION
config TOCTOU_SAFETY config TOCTOU_SAFETY
bool bool "Protect against time-of-check vs. time-of-use vulnerabilities"
depends on CBFS_VERIFICATION
depends on !NO_FMAP_CACHE depends on !NO_FMAP_CACHE
depends on !NO_CBFS_MCACHE depends on !NO_CBFS_MCACHE
depends on !USE_OPTION_TABLE && !FSP_CAR # Known to access CBFS before CBMEM init depends on !USE_OPTION_TABLE && !FSP_CAR # Known to access CBFS before CBMEM init
depends on !VBOOT # TODO: can only allow this once vboot fully integrated
depends on NO_XIP_EARLY_STAGES
help help
Work in progress. Not actually TOCTOU safe yet. Do not use. Say yes here to eliminate time-of-check vs. time-of-use vulnerabilities
for CBFS verification. This means that data from flash must be verified
every time it is loaded (not just the first time), which requires a bit
more overhead and is incompatible with certain configurations.
Design idea here is that mcache overflows in this mode are only legal Using this option only makes sense when the mechanism securing the
for the RW CBFS, because it's relatively easy to retrieve the RW bootblock is also safe against these vulnerabilities (i.e. there's no
metadata hash from persistent vboot context at any time, but the RO point in enabling this when you just rely on flash write-protection).
metadata hash is lost after the bootblock is unloaded. This avoids the
need to carry yet another piece forward through the stages. Mcache
overflows are mostly a concern for RW updates (if an update adds more
files than originally planned for), for the RO section it should
always be possible to dimension the mcache correctly beforehand, so
this should be an acceptable limitation.
config CBFS_HASH_ALGO config CBFS_HASH_ALGO
int int
@ -37,9 +45,13 @@ config CBFS_HASH_ALGO
default 3 if CBFS_HASH_SHA512 default 3 if CBFS_HASH_SHA512
choice choice
prompt "--> hash type" prompt "Hash algorithm"
depends on CBFS_VERIFICATION
default CBFS_HASH_SHA256 default CBFS_HASH_SHA256
help
Select the hash algorithm used in CBFS verification. Note that SHA-1 is
generally considered insecure today and should not be used without good
reason. When using CBFS verification together with measured boot, using
the same hash algorithm (usually SHA-256) for both is more efficient.
config CBFS_HASH_SHA1 config CBFS_HASH_SHA1
bool "SHA-1" bool "SHA-1"
@ -52,4 +64,6 @@ config CBFS_HASH_SHA512
endchoice endchoice
#endmenu endif
endmenu

2
src/lib/cbfs.c
View File

@ -57,7 +57,7 @@ cb_err_t _cbfs_boot_lookup(const char *name, bool force_ro,
RO CBFS would have been caught when building the mcache in cbfs_get RO CBFS would have been caught when building the mcache in cbfs_get
boot_device(). (Note that TOCTOU_SAFETY implies !NO_CBFS_MCACHE.) */ boot_device(). (Note that TOCTOU_SAFETY implies !NO_CBFS_MCACHE.) */
assert(cbd == vboot_get_cbfs_boot_device()); assert(cbd == vboot_get_cbfs_boot_device());
/* TODO: set metadata_hash to RW metadata hash here. */ die("TODO: set metadata_hash to RW metadata hash here.\n");
} }
err = cbfs_lookup(&cbd->rdev, name, mdata, &data_offset, metadata_hash); err = cbfs_lookup(&cbd->rdev, name, mdata, &data_offset, metadata_hash);
} }