blob: fa90d9d9af0b35d8cb08362c7c42716bd92444f1 (
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
|
# 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
|
