diff options
| author | Simon Glass <[email protected]> | 2026-03-05 18:20:09 -0700 |
|---|---|---|
| committer | Tom Rini <[email protected]> | 2026-03-09 09:49:50 -0600 |
| commit | 2092322b31cc8b1f8c9e2e238d1043ae0637b241 (patch) | |
| tree | 4fc75ff4ae16fc2727d1c445370c43baddafde90 /doc | |
| parent | 532a4804e965f001db6aec9ffc2ce0639eb3cf25 (diff) | |
boot: Add fit_config_get_hash_list() to build signed node list
The hashed-nodes property in a FIT signature node lists which FDT paths
are included in the signature hash. It is intended as a hint so should
not be used for verification.
Add a function to build the node list from scratch by iterating the
configuration's image references. Skip properties known not to be image
references. For each image, collect the path plus all hash and cipher
subnodes.
Use the new function in fit_config_check_sig() instead of reading
'hashed-nodes'.
Update the test_vboot kernel@ test case: fit_check_sign now catches the
attack at signature-verification time (the @-suffixed node is hashed
instead of the real one, causing a mismatch) rather than at
fit_check_format() time.
Update the docs to cover this. The FIT spec can be updated separately.
Signed-off-by: Simon Glass <[email protected]>
Closes: https://lore.kernel.org/u-boot/[email protected]/
Reported-by: Apple Security Engineering and Architecture (SEAR)
Tested-by: Tom Rini <[email protected]>
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/usage/fit/signature.rst | 19 |
1 files changed, 13 insertions, 6 deletions
diff --git a/doc/usage/fit/signature.rst b/doc/usage/fit/signature.rst index e5b5a8432e9..da08cc75c3a 100644 --- a/doc/usage/fit/signature.rst +++ b/doc/usage/fit/signature.rst @@ -353,20 +353,27 @@ meantime. Details ------- The signature node contains a property ('hashed-nodes') which lists all the -nodes that the signature was made over. The image is walked in order and each -tag processed as follows: +nodes that the signature was made over. The signer (mkimage) writes this +property as a record of what was included in the hash. During verification, +however, U-Boot does not read 'hashed-nodes'. Instead it rebuilds the node +list from the configuration's own image references (kernel, fdt, ramdisk, +etc.), since 'hashed-nodes' is not itself covered by the signature. The +rebuilt list always includes the root node, the configuration node, each +referenced image node and its hash/cipher subnodes. + +The image is walked in order and each tag processed as follows: DTB_BEGIN_NODE The tag and the following name are included in the signature - if the node or its parent are present in 'hashed-nodes' + if the node or its parent are present in the node list DTB_END_NODE The tag is included in the signature if the node or its parent - are present in 'hashed-nodes' + are present in the node list DTB_PROPERTY The tag, the length word, the offset in the string table, and - the data are all included if the current node is present in 'hashed-nodes' + the data are all included if the current node is present in the node list and the property name is not 'data'. DTB_END @@ -374,7 +381,7 @@ DTB_END DTB_NOP The tag is included in the signature if the current node is present - in 'hashed-nodes' + in the node list In addition, the signature contains a property 'hashed-strings' which contains the offset and length in the string table of the strings that are to be |