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.rey...@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.rey...@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
