From 838404054e406e82938cbf7be7f90cce058d453b Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Mon, 4 Dec 2017 02:05:07 +0000 Subject: doc: FIT image: fix incorrect description of DT node unit address The DT spec demands a unit-address in a node name to match the "reg" property in that node. Newer dtc versions will throw warnings if this is not the case. Fix all occurences in the FIT image documentation files where this was not observed, to not give bad examples to the reader. Signed-off-by: Andre Przywara --- doc/uImage.FIT/signature.txt | 100 +++++++++++++++++++++---------------------- 1 file changed, 50 insertions(+), 50 deletions(-) (limited to 'doc/uImage.FIT/signature.txt') diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt index 2ece4c47de..a765722679 100644 --- a/doc/uImage.FIT/signature.txt +++ b/doc/uImage.FIT/signature.txt @@ -83,7 +83,7 @@ Device Tree Bindings The following properties are required in the FIT's signature node(s) to allow the signer to operate. These should be added to the .its file. Signature nodes sit at the same level as hash nodes and are called -signature@1, signature@2, etc. +signature-1, signature-2, etc. - algo: Algorithm name (e.g. "sha1,rsa2048") @@ -118,9 +118,9 @@ For config bindings, these properties are added by the signer: - hashed-nodes: A list of nodes which were hashed by the signer. Each is a string - the full path to node. A typical value might be: - hashed-nodes = "/", "/configurations/conf@1", "/images/kernel@1", - "/images/kernel@1/hash@1", "/images/fdt@1", - "/images/fdt@1/hash@1"; + hashed-nodes = "/", "/configurations/conf-1", "/images/kernel", + "/images/kernel/hash-1", "/images/fdt-1", + "/images/fdt-1/hash-1"; - hashed-strings: The start and size of the string region of the FIT that was hashed @@ -178,44 +178,44 @@ As an example, consider this FIT: / { images { - kernel@1 { + kernel-1 { data = - signature@1 { + signature-1 { algo = "sha1,rsa2048"; value = <...kernel signature 1...> }; }; - kernel@2 { + kernel-2 { data = - signature@1 { + signature-1 { algo = "sha1,rsa2048"; value = <...kernel signature 2...> }; }; - fdt@1 { + fdt-1 { data = ; - signature@1 { + signature-1 { algo = "sha1,rsa2048"; vaue = <...fdt signature 1...> }; }; - fdt@2 { + fdt-2 { data = ; - signature@1 { + signature-1 { algo = "sha1,rsa2048"; vaue = <...fdt signature 2...> }; }; }; configurations { - default = "conf@1"; - conf@1 { - kernel = "kernel@1"; - fdt = "fdt@1"; + default = "conf-1"; + conf-1 { + kernel = "kernel-1"; + fdt = "fdt-1"; }; - conf@1 { - kernel = "kernel@2"; - fdt = "fdt@2"; + conf-1 { + kernel = "kernel-2"; + fdt = "fdt-2"; }; }; }; @@ -224,18 +224,18 @@ Since both kernels are signed it is easy for an attacker to add a new configuration 3 with kernel 1 and fdt 2: configurations { - default = "conf@1"; - conf@1 { - kernel = "kernel@1"; - fdt = "fdt@1"; + default = "conf-1"; + conf-1 { + kernel = "kernel-1"; + fdt = "fdt-1"; }; - conf@1 { - kernel = "kernel@2"; - fdt = "fdt@2"; + conf-1 { + kernel = "kernel-2"; + fdt = "fdt-2"; }; - conf@3 { - kernel = "kernel@1"; - fdt = "fdt@2"; + conf-3 { + kernel = "kernel-1"; + fdt = "fdt-2"; }; }; @@ -250,49 +250,49 @@ So the above example is adjusted to look like this: / { images { - kernel@1 { + kernel-1 { data = - hash@1 { + hash-1 { algo = "sha1"; value = <...kernel hash 1...> }; }; - kernel@2 { + kernel-2 { data = - hash@1 { + hash-1 { algo = "sha1"; value = <...kernel hash 2...> }; }; - fdt@1 { + fdt-1 { data = ; - hash@1 { + hash-1 { algo = "sha1"; value = <...fdt hash 1...> }; }; - fdt@2 { + fdt-2 { data = ; - hash@1 { + hash-1 { algo = "sha1"; value = <...fdt hash 2...> }; }; }; configurations { - default = "conf@1"; - conf@1 { - kernel = "kernel@1"; - fdt = "fdt@1"; - signature@1 { + default = "conf-1"; + conf-1 { + kernel = "kernel-1"; + fdt = "fdt-1"; + signature-1 { algo = "sha1,rsa2048"; value = <...conf 1 signature...>; }; }; - conf@2 { - kernel = "kernel@2"; - fdt = "fdt@2"; - signature@1 { + conf-2 { + kernel = "kernel-2"; + fdt = "fdt-2"; + signature-1 { algo = "sha1,rsa2048"; value = <...conf 1 signature...>; }; @@ -303,11 +303,11 @@ So the above example is adjusted to look like this: You can see that we have added hashes for all images (since they are no longer signed), and a signature to each configuration. In the above example, -mkimage will sign configurations/conf@1, the kernel and fdt that are -pointed to by the configuration (/images/kernel@1, /images/kernel@1/hash@1, -/images/fdt@1, /images/fdt@1/hash@1) and the root structure of the image +mkimage will sign configurations/conf-1, the kernel and fdt that are +pointed to by the configuration (/images/kernel-1, /images/kernel-1/hash-1, +/images/fdt-1, /images/fdt-1/hash-1) and the root structure of the image (so that it isn't possible to add or remove root nodes). The signature is -written into /configurations/conf@1/signature@1/value. It can easily be +written into /configurations/conf-1/signature-1/value. It can easily be verified later even if the FIT has been signed with other keys in the meantime. -- cgit v1.2.1