[PATCH v6 07/16] boot: image: add a stage pre-load

[Philippe REYNES]

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 at 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 at 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