34cf073220
This patch addresses the same problem as CB:48429, but hopefully this time correctly. Since the mcache is not guaranteed to be available on the first CBFS lookup for some special cases, we can no longer treat it as a one-time fire-and-forget initialization. Instead, we test cbd->mcache_size to check if the mcache has been initialized yet, and keep trying on every lookup if we don't find it the first time. Since the mcache is a hard requirement for TOCTOU safety, also make it more clear in Kconfig that configurations known to do CBFS accesses before CBMEM init are incompatbile with that, and make sure we die() rather than do something unsafe if there's a case that Kconfig didn't catch. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I4e01e9a9905f7dcba14eaf05168495201ed5de60 Reviewed-on: https://review.coreboot.org/c/coreboot/+/48482 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Christian Walter <christian.walter@9elements.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
59 lines
1.7 KiB
Plaintext
59 lines
1.7 KiB
Plaintext
# SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0-or-later
|
|
#
|
|
# This file is part of the coreboot project.
|
|
#
|
|
# 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 !COMPRESS_BOOTBLOCK # TODO: figure out decompressor anchor
|
|
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
|