blob: fa90d9d9af0b35d8cb08362c7c42716bd92444f1 [file] [log] [blame]
Julius Wernerfdabf3f2020-05-06 17:06:35 -07001# SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0-or-later
2#
Julius Wernerfdabf3f2020-05-06 17:06:35 -07003# This file is sourced from src/security/Kconfig for menuconfig convenience.
4
5#menu "CBFS verification" # TODO: enable once it works
6
7config CBFS_VERIFICATION
8 bool # TODO: make user selectable once it works
Julius Wernerfdabf3f2020-05-06 17:06:35 -07009 depends on !VBOOT_STARTS_BEFORE_BOOTBLOCK # this is gonna get tricky...
10 select VBOOT_LIB
11 help
12 Work in progress. Do not use (yet).
13
14config TOCTOU_SAFETY
15 bool
16 depends on CBFS_VERIFICATION
17 depends on !NO_FMAP_CACHE
18 depends on !NO_CBFS_MCACHE
Julius Werner34cf0732020-12-08 14:21:43 -080019 depends on !USE_OPTION_TABLE && !FSP_CAR # Known to access CBFS before CBMEM init
Julius Wernerfdabf3f2020-05-06 17:06:35 -070020 help
21 Work in progress. Not actually TOCTOU safe yet. Do not use.
22
23 Design idea here is that mcache overflows in this mode are only legal
24 for the RW CBFS, because it's relatively easy to retrieve the RW
25 metadata hash from persistent vboot context at any time, but the RO
26 metadata hash is lost after the bootblock is unloaded. This avoids the
27 need to carry yet another piece forward through the stages. Mcache
28 overflows are mostly a concern for RW updates (if an update adds more
29 files than originally planned for), for the RO section it should
30 always be possible to dimension the mcache correctly beforehand, so
31 this should be an acceptable limitation.
32
33config CBFS_HASH_ALGO
34 int
35 default 1 if CBFS_HASH_SHA1
36 default 2 if CBFS_HASH_SHA256
37 default 3 if CBFS_HASH_SHA512
38
39choice
40 prompt "--> hash type"
41 depends on CBFS_VERIFICATION
42 default CBFS_HASH_SHA256
43
44config CBFS_HASH_SHA1
45 bool "SHA-1"
46
47config CBFS_HASH_SHA256
48 bool "SHA-256"
49
50config CBFS_HASH_SHA512
51 bool "SHA-512"
52
53endchoice
54
55#endmenu