coreboot-kgpe-d16/src/lib/Kconfig.cbfs_verification
Julius Werner 6296ca8ad9 decompressor: Add CBFS_VERIFICATION support
CBFS_VERIFICATION requires the CBFS metadata hash anchor to be linked
into an uncompressed stage, but for platforms using COMPRESS_BOOTBLOCK,
this is only the decompressor stage. The first CBFS accesses are made in
the bootblock stage after decompression, so if we want to make
CBFS_VERIFICATION work on those platforms, we have to pass the metadata
hash anchor from the decompressor into the bootblock. This patch does
just that. (Note that this relies on the decompressor data remaining
valid in memory for as long as the metadata hash anchor is needed. This
is always true even for OVERLAP_DECOMPRESSOR_ROMSTAGE() situations
because the FMAP and CBFS metadata necessarily need to have finished
verification before a new stage could be loaded.)

Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I2e6d7384cfb8339a24369eb6c01fc12f911c974e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52085
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-04-06 07:49:15 +00:00

55 lines
1.6 KiB
Text

# SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0-or-later
#
# This file is sourced from src/security/Kconfig for menuconfig convenience.
#menu "CBFS verification" # TODO: enable once it works
config CBFS_VERIFICATION
bool # TODO: make user selectable once it works
depends on !VBOOT_STARTS_BEFORE_BOOTBLOCK # this is gonna get tricky...
select VBOOT_LIB
help
Work in progress. Do not use (yet).
config TOCTOU_SAFETY
bool
depends on CBFS_VERIFICATION
depends on !NO_FMAP_CACHE
depends on !NO_CBFS_MCACHE
depends on !USE_OPTION_TABLE && !FSP_CAR # Known to access CBFS before CBMEM init
help
Work in progress. Not actually TOCTOU safe yet. Do not use.
Design idea here is that mcache overflows in this mode are only legal
for the RW CBFS, because it's relatively easy to retrieve the RW
metadata hash from persistent vboot context at any time, but the RO
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
int
default 1 if CBFS_HASH_SHA1
default 2 if CBFS_HASH_SHA256
default 3 if CBFS_HASH_SHA512
choice
prompt "--> hash type"
depends on CBFS_VERIFICATION
default CBFS_HASH_SHA256
config CBFS_HASH_SHA1
bool "SHA-1"
config CBFS_HASH_SHA256
bool "SHA-256"
config CBFS_HASH_SHA512
bool "SHA-512"
endchoice
#endmenu