summaryrefslogtreecommitdiff
path: root/src/lib/Kconfig.cbfs_verification
blob: 4e2ed8cf01f3bbcee36618c90fda30dafdb88596 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
# 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