Hi Simon,
Le 03/03/2022 à 04:37, Simon Glass a écrit :
Hi Philippe,
On Fri, 25 Feb 2022 at 07:58, Philippe Reynes philippe.reynes@softathome.com wrote:
Add a stage pre-load that could check or modify an image.
For the moment, only a header with a signature is supported. This header has the following format:
- magic : 4 bytes
- version : 4 bytes
- header size : 4 bytes
- image size : 4 bytes
- offset image signature : 4 bytes
- flags : 4 bytes
- reserved0 : 4 bytes
- reserved1 : 4 bytes
- sha256 of the image signature : 32 bytes
- signature of the first 64 bytes : n bytes
It is a bit hard to understand without docs, but what is the point of taking the sha256 of the signature?
Also, why is the signature only of the first 64 bytes? Normally we hash the whole image and then sign that.
The size of the header is dynamic and specified in the header. The golden rule is: no data is used before being checked. To check the header, the size of the header is needed, but as this size is in the header and the header is not checked yet, it is not possible to read/use it.
So to check the header, we use a two steps scheme: 1) the first 64 bytes of the header contains informations about the header, call it header_header. As this header_header has a fixed size, it possible to check its signature. 2) the header_header contains a hash of the image signature, and its offset in the header. So it is possible to check the hash of the image signature.
After those two steps, the image signature contained in the header is checked and can be used to verify the signature of the image.
So the golden rule is respected, no data are used before being checked.
- image signature : n bytes
- padding : up to header size
The stage uses a node /image/pre-load/sig to get some informations:
- algo-name (mandatory) : name of the algo used to sign
- padding-name : name of padding used to sign
- signature-size : size of the signature (in the header)
- mandatory : set to yes if this sig is mandatory
- public-key (madatory) : value of the public key
Does this mean you read the DT properties to find out the sig info? I thought the point of this series was to have a signature check that did not rely on the devicetree, i.e. another layer of security?
Yes, some properties are in the device tree, like the name of the algo (sha256,rsa4096, ....), the padding name, the signature size, the public key, and if a signature is mandatory before launching a binary with bootm.
The first goal of this serie is to be able to verify the signature of an image without using data not yet verified. If the signature is in the FIT image, the header of the fit, and some node of the fit must be read and used before verifying the signature of the FIT.
Another goal appears with this serie, to be able to verify the signature of other binary than FIT (script, firmware, ...).
Before running the image, the stage pre-load checks the signature provided in the header.
This is an initial support, later we could add the support of:
- ciphering
- uncompressing
- ...
Signed-off-by: Philippe Reynes philippe.reynes@softathome.com
boot/Kconfig | 55 ++++++ boot/Makefile | 1 + boot/image-pre-load.c | 416 ++++++++++++++++++++++++++++++++++++++++++ include/image.h | 14 ++ 4 files changed, 486 insertions(+) create mode 100644 boot/image-pre-load.c
Regards, Simon
Regards, Philippe