All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] spl: Add callback for preprocessing loaded FIT header before parsing
@ 2021-02-24 23:25 Farhan Ali
  2021-03-09 23:55 ` [PATCH v2] " Farhan Ali
  0 siblings, 1 reply; 12+ messages in thread
From: Farhan Ali @ 2021-02-24 23:25 UTC (permalink / raw)
  To: u-boot

This change adds a callback for preprocessing the FIT header before
it is parsed. There are 3 main reasons for this callback:

(1) If a vulnerability is discovered in the FIT parsing/loading code,
or libfdt, this callback allows users to scan the FIT header for
specific exploit signatures and prevent flashing/booting of the image

(2) If users want to implement a single signature which covers the
entire FIT header, which is then appended to the end of the header,
then this callback can be used to authenticate that signature.

(3) If users want to check the FIT header contents against specific
metadata stored outside the FIT header, then this callback allows
them to do that.

Signed-off-by: Farhan Ali <farhan.ali@broadcom.com>
---
Cc: Simon Glass <sjg@chromium.org>
Cc: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Philippe Reynes <philippe.reynes@softathome.com>
Cc: Samuel Holland <samuel@sholland.org>

 common/spl/spl_fit.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 75c8ff0..e03c67b 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -43,6 +43,12 @@ __weak ulong board_spl_fit_size_align(ulong size)
 	return size;
 }
 
+__weak void board_spl_fit_pre_load(struct spl_load_info *load_info, void *fit,
+				   ulong start_sector,
+				   ulong loaded_sector_count)
+{
+}
+
 static int find_node_from_desc(const void *fit, int node, const char *str)
 {
 	int child;
@@ -552,6 +558,9 @@ static int spl_simple_fit_read(struct spl_fit_info *ctx,
 	debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu, size=0x%lx\n",
 	      sector, sectors, buf, count, size);
 
+	/* preprocess loaded fit header before parsing and loading binaries */
+	board_spl_fit_pre_load(info, fit_header, sector, sectors);
+
 	return (count == 0) ? -EIO : 0;
 }
 
-- 
1.8.3.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210224/82a35909/attachment.bin>

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
  2021-02-24 23:25 [PATCH] spl: Add callback for preprocessing loaded FIT header before parsing Farhan Ali
@ 2021-03-09 23:55 ` Farhan Ali
  2021-03-10 19:38   ` Alex G.
  0 siblings, 1 reply; 12+ messages in thread
From: Farhan Ali @ 2021-03-09 23:55 UTC (permalink / raw)
  To: u-boot

This change adds a callback for preprocessing the FIT header before
it is parsed. There are 3 main reasons for this callback:

(1) If a vulnerability is discovered in the FIT parsing/loading code,
or libfdt, this callback allows users to scan the FIT header for
specific exploit signatures and prevent flashing/booting of the image

(2) If users want to implement a single signature which covers the
entire FIT header, which is then appended to the end of the header,
then this callback can be used to authenticate that signature.

(3) If users want to check the FIT header contents against specific
metadata stored outside the FIT header, then this callback allows
them to do that.

Signed-off-by: Farhan Ali <farhan.ali@broadcom.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Philippe Reynes <philippe.reynes@softathome.com>
Cc: Samuel Holland <samuel@sholland.org>

---
Changes for v2:
   - Callback now returns a value
   - Added a log message on failure
---
 common/spl/spl_fit.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 75c8ff0..01aee1c 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -43,6 +43,14 @@ __weak ulong board_spl_fit_size_align(ulong size)
 	return size;
 }
 
+__weak int board_spl_fit_pre_load(struct spl_load_info *load_info,
+				  const void *fit,
+				  ulong start_sector,
+				  ulong loaded_sector_count)
+{
+	return 0;
+}
+
 static int find_node_from_desc(const void *fit, int node, const char *str)
 {
 	int child;
@@ -527,6 +535,7 @@ static int spl_simple_fit_read(struct spl_fit_info *ctx,
 	unsigned long count, size;
 	int sectors;
 	void *buf;
+	int rc = 0;
 
 	/*
 	 * For FIT with external data, figure out where the external images
@@ -552,7 +561,18 @@ static int spl_simple_fit_read(struct spl_fit_info *ctx,
 	debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu, size=0x%lx\n",
 	      sector, sectors, buf, count, size);
 
-	return (count == 0) ? -EIO : 0;
+	if (count) {
+		/* preprocess loaded fit header before parsing and loading binaries */
+		rc = board_spl_fit_pre_load(info, fit_header, sector, sectors);
+		if (rc) {
+			debug("%s: fit header pre processing failed. rc=%d\n",
+			      __func__, rc);
+		}
+	} else {
+		rc = -EIO;
+	}
+
+	return rc;
 }
 
 static int spl_simple_fit_parse(struct spl_fit_info *ctx)
-- 
1.8.3.1

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
  2021-03-09 23:55 ` [PATCH v2] " Farhan Ali
@ 2021-03-10 19:38   ` Alex G.
  2021-03-10 20:49     ` Farhan Ali
  0 siblings, 1 reply; 12+ messages in thread
From: Alex G. @ 2021-03-10 19:38 UTC (permalink / raw)
  To: u-boot

On 3/9/21 5:55 PM, Farhan Ali wrote:
> This change adds a callback for preprocessing the FIT header before
> it is parsed. There are 3 main reasons for this callback:
> 
> (1) If a vulnerability is discovered in the FIT parsing/loading code,
> or libfdt, this callback allows users to scan the FIT header for
> specific exploit signatures and prevent flashing/booting of the image
> 
> (2) If users want to implement a single signature which covers the
> entire FIT header, which is then appended to the end of the header,
> then this callback can be used to authenticate that signature.
> 
> (3) If users want to check the FIT header contents against specific
> metadata stored outside the FIT header, then this callback allows
> them to do that.

Hi Fahran,

This patch describes "how" you're trying to achieve it, but "what" you 
want to achieve. I'll get later into why I think the "how" is 
fundamentally flawed.

There should be at least a use case implemented in this series. When 
someone notices an empty function that isn't used, the first instinct 
would be to submit a patch to remove it. But more importantly, seeing an 
actual example of "what" you are trying to achieve will help others 
suggest a better way on "how" to achieve it.

Second issue is that spl_simple_fit_read() is intended to bring a FIT 
image to memory. If you need to make decisions on the content of that 
image, then spl_simple_fit_read() is the wrong place to do it. A better 
place might be spl_simple_fit_parse().

The third issue is that whatever the end goal is, you're trying to 
achieve it with weak functions. Weak functions aren't always bad. There 
are a limited number of cases where they work very well for the purpose 
-- I've even used them before. But to introduce a weak function, a 
really strong argument is needed. Maybe you have it, but that argument 
needs to be made clear.

Let's assume board 'c' implements this. Then later someone with board 
'd' implements this at the SOC level. Does board 'c' get the old 
implementation, or the new? Things become ambiguous in everything but 
the simplest of cases.

A more elegant way would be to have a proper interface to hook into the 
FIT processing. That could be done by a function pointer, ops structure, 
or perhaps new UCLASS (Simon?).

Alex




> Signed-off-by: Farhan Ali <farhan.ali@broadcom.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: Philippe Reynes <philippe.reynes@softathome.com>
> Cc: Samuel Holland <samuel@sholland.org>
> 
> ---
> Changes for v2:
>     - Callback now returns a value
>     - Added a log message on failure
> ---
>   common/spl/spl_fit.c | 22 +++++++++++++++++++++-
>   1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index 75c8ff0..01aee1c 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -43,6 +43,14 @@ __weak ulong board_spl_fit_size_align(ulong size)
>   	return size;
>   }
>   
> +__weak int board_spl_fit_pre_load(struct spl_load_info *load_info,
> +				  const void *fit,
> +				  ulong start_sector,
> +				  ulong loaded_sector_count)
> +{
> +	return 0;
> +}
> +
>   static int find_node_from_desc(const void *fit, int node, const char *str)
>   {
>   	int child;
> @@ -527,6 +535,7 @@ static int spl_simple_fit_read(struct spl_fit_info *ctx,
>   	unsigned long count, size;
>   	int sectors;
>   	void *buf;
> +	int rc = 0;
>   
>   	/*
>   	 * For FIT with external data, figure out where the external images
> @@ -552,7 +561,18 @@ static int spl_simple_fit_read(struct spl_fit_info *ctx,
>   	debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu, size=0x%lx\n",
>   	      sector, sectors, buf, count, size);
>   
> -	return (count == 0) ? -EIO : 0;
> +	if (count) {
> +		/* preprocess loaded fit header before parsing and loading binaries */
> +		rc = board_spl_fit_pre_load(info, fit_header, sector, sectors);
> +		if (rc) {
> +			debug("%s: fit header pre processing failed. rc=%d\n",
> +			      __func__, rc);
> +		}
> +	} else {
> +		rc = -EIO;
> +	}
> +
> +	return rc;
>   }
>   
>   static int spl_simple_fit_parse(struct spl_fit_info *ctx)
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
  2021-03-10 19:38   ` Alex G.
@ 2021-03-10 20:49     ` Farhan Ali
  2021-03-10 23:10       ` Alex G
  0 siblings, 1 reply; 12+ messages in thread
From: Farhan Ali @ 2021-03-10 20:49 UTC (permalink / raw)
  To: u-boot

On Wed, Mar 10, 2021 at 11:38 AM Alex G. <mr.nuke.me@gmail.com> wrote:

> On 3/9/21 5:55 PM, Farhan Ali wrote:
> > This change adds a callback for preprocessing the FIT header before
> > it is parsed. There are 3 main reasons for this callback:
> >
> > (1) If a vulnerability is discovered in the FIT parsing/loading code,
> > or libfdt, this callback allows users to scan the FIT header for
> > specific exploit signatures and prevent flashing/booting of the image
> >
> > (2) If users want to implement a single signature which covers the
> > entire FIT header, which is then appended to the end of the header,
> > then this callback can be used to authenticate that signature.
> >
> > (3) If users want to check the FIT header contents against specific
> > metadata stored outside the FIT header, then this callback allows
> > them to do that.
>
> Hi Fahran,
>
> This patch describes "how" you're trying to achieve it, but "what" you
> want to achieve. I'll get later into why I think the "how" is
> fundamentally flawed.
>
> Hi Alex,
The 'what' is basically this: I want to be able to parse the fit header for
correctness before
any image loading takes place. This 'correctness' will be user defined
The 'how' is this: A weak function which is invoked right after the fit
HEADER ONLY is read.

There should be at least a use case implemented in this series. When
> someone notices an empty function that isn't used, the first instinct
> would be to submit a patch to remove it. But more importantly, seeing an
> actual example of "what" you are trying to achieve will help others
> suggest a better way on "how" to achieve it.
>
>  The main use case for us is two folds:
(1) Customers are worried about our reliance on libfdt for FIT parsing and
want to prescan the FIT header to
check for any future exploits
(2) We implement a signature on the entire FIT header ( instead of
individual nodes ). This speeds
up the signing process for production/development builds. We want to be
able validate this signature
before the FIT parsing starts. Signature is stored elsewhere, outside the
FIT header.

Second issue is that spl_simple_fit_read() is intended to bring a FIT
> image to memory. If you need to make decisions on the content of that
> image, then spl_simple_fit_read() is the wrong place to do it. A better
> place might be spl_simple_fit_parse().
>
spl_simple_fit_parse()  parses the 'contents' of the fit using standard
APIs. We need to check
the FIT header for correctness BEFORE its contents are parsed, using a user
defined 'safe'
parsing function. The standard FIT loading flow checks for only a few
things ( hashes/configuration etc),
there can be a lot of other USER defined checks which may need to be
checked. This callback will achieve this

The third issue is that whatever the end goal is, you're trying to
> achieve it with weak functions. Weak functions aren't always bad. There
> are a limited number of cases where they work very well for the purpose
> -- I've even used them before. But to introduce a weak function, a
> really strong argument is needed. Maybe you have it, but that argument
> needs to be made clear.
>
> The reason I used a weak function was to mirror the already
upstreamed board_spl_fit_post_load(), I
thought that the justifications for that function would also apply to this
new board_spl_fit_pre_load().
If board_spl_fit_pre_load() is fundamentally different in some aspect, then
I am happy to look for an
alternative implementation.

Regards,

Farhan

> Let's assume board 'c' implements this. Then later someone with board
> 'd' implements this at the SOC level. Does board 'c' get the old
> implementation, or the new? Things become ambiguous in everything but
> the simplest of cases.
>
> A more elegant way would be to have a proper interface to hook into the
> FIT processing. That could be done by a function pointer, ops structure,
> or perhaps new UCLASS (Simon?).
>
> Alex
>
>
>
>
> > Signed-off-by: Farhan Ali <farhan.ali@broadcom.com>
> > Cc: Simon Glass <sjg@chromium.org>
> > Cc: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> > Cc: Marek Vasut <marex@denx.de>
> > Cc: Michal Simek <michal.simek@xilinx.com>
> > Cc: Philippe Reynes <philippe.reynes@softathome.com>
> > Cc: Samuel Holland <samuel@sholland.org>
> >
> > ---
> > Changes for v2:
> >     - Callback now returns a value
> >     - Added a log message on failure
> > ---
> >   common/spl/spl_fit.c | 22 +++++++++++++++++++++-
> >   1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> > index 75c8ff0..01aee1c 100644
> > --- a/common/spl/spl_fit.c
> > +++ b/common/spl/spl_fit.c
> > @@ -43,6 +43,14 @@ __weak ulong board_spl_fit_size_align(ulong size)
> >       return size;
> >   }
> >
> > +__weak int board_spl_fit_pre_load(struct spl_load_info *load_info,
> > +                               const void *fit,
> > +                               ulong start_sector,
> > +                               ulong loaded_sector_count)
> > +{
> > +     return 0;
> > +}
> > +
> >   static int find_node_from_desc(const void *fit, int node, const char
> *str)
> >   {
> >       int child;
> > @@ -527,6 +535,7 @@ static int spl_simple_fit_read(struct spl_fit_info
> *ctx,
> >       unsigned long count, size;
> >       int sectors;
> >       void *buf;
> > +     int rc = 0;
> >
> >       /*
> >        * For FIT with external data, figure out where the external images
> > @@ -552,7 +561,18 @@ static int spl_simple_fit_read(struct spl_fit_info
> *ctx,
> >       debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu,
> size=0x%lx\n",
> >             sector, sectors, buf, count, size);
> >
> > -     return (count == 0) ? -EIO : 0;
> > +     if (count) {
> > +             /* preprocess loaded fit header before parsing and loading
> binaries */
> > +             rc = board_spl_fit_pre_load(info, fit_header, sector,
> sectors);
> > +             if (rc) {
> > +                     debug("%s: fit header pre processing failed.
> rc=%d\n",
> > +                           __func__, rc);
> > +             }
> > +     } else {
> > +             rc = -EIO;
> > +     }
> > +
> > +     return rc;
> >   }
> >
> >   static int spl_simple_fit_parse(struct spl_fit_info *ctx)
> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210310/ec52263e/attachment.bin>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
  2021-03-10 20:49     ` Farhan Ali
@ 2021-03-10 23:10       ` Alex G
  2021-03-22 14:27         ` Philippe REYNES
  0 siblings, 1 reply; 12+ messages in thread
From: Alex G @ 2021-03-10 23:10 UTC (permalink / raw)
  To: u-boot

On 3/10/21 2:49 PM, Farhan Ali wrote:
> On Wed, Mar 10, 2021 at 11:38 AM Alex G. <mr.nuke.me@gmail.com 
>     This patch describes "how" you're trying to achieve it, but "what" you
>     want to achieve. I'll get later into why I think the "how" is
>     fundamentally flawed.
> 
> The 'what' is basically this: I want to be able to parse the fit header 
> for correctness before
> any image loading takes place. This 'correctness' will be user defined

I'd expect such code to be part of this series. Having a function that a 
"user" might define sounds a lot like a vendor-specific hook with no 
upstream code, hence the skepticism. This series should include a useful 
implementation of board_spl_fit_pre_load().


>  ?The main use case for us is two folds:
> (1) Customers are worried about our reliance on libfdt for FIT parsing 
> and want to prescan the FIT header to
> check for any future exploits
> (2) We implement a signature on the entire FIT header ( instead of 
> individual nodes ).

Do you believe the current FIT signing scheme is inappropriate for your 
needs? Have you looked at signed configs? Is there a reason why they are 
not appropriate?

There was a potential issue where a bad FIT could place itself anywhere 
in memory. This was fixed in commit 03f1f78a9b ("spl: fit: Prefer a 
malloc()'d buffer for loading images"). Keep in mind that, in this case, 
checking the FIT header would not have guarded against the exploit.


>     Second issue is that spl_simple_fit_read() is intended to bring a FIT
>     image to memory. If you need to make decisions on the content of that
>     image, then spl_simple_fit_read() is the wrong place to do it. A better
>     place might be spl_simple_fit_parse().
> 
> spl_simple_fit_parse()? parses the 'contents' of the fit using standard 
> APIs. We need to check
> the FIT header for correctness BEFORE its contents are parsed, using a 
> user defined 'safe'
> parsing function. The standard FIT loading flow checks for only a few 
> things ( hashes/configuration etc),
> there can be a lot of other USER defined checks which may need to be 
> checked. This callback will achieve this

This patch is calling board_spl_fit_pre_load() after the FIT is read. On 
a FIT with embedded data, you've also loaded all the binaries. It seems 
that checking a header now is a moot point.

If you need to make sure that the FIT wasn't tampered, the signed 
configs were designed exactly for that. You mentioned earlier that you 
want to sign the FIT header. What is the FIT header in this case? Is it 
the FDT of a FIT with external data? Is it struct fdt_header?


> The reason I used a weak function was to mirror the already 
> upstreamed?board_spl_fit_post_load(),

I see why you'd think it was a good idea. board_spl_fit_pre_load() 
sneaks in a dependency on arch-specific code (CONFIG_IMX_HAB). I don't 
really like the way it's implemented, and I don't know if it would work 
with SPL_LOAD_FIT_FULL or bootm.

Alex

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
  2021-03-10 23:10       ` Alex G
@ 2021-03-22 14:27         ` Philippe REYNES
  2021-03-22 15:12           ` Alex G.
  0 siblings, 1 reply; 12+ messages in thread
From: Philippe REYNES @ 2021-03-22 14:27 UTC (permalink / raw)
  To: u-boot

Hi all,


Le 11/03/2021 ? 00:10, Alex G a ?crit?:
> On 3/10/21 2:49 PM, Farhan Ali wrote:
>> On Wed, Mar 10, 2021 at 11:38 AM Alex G. <mr.nuke.me@gmail.com ??? 
>> This patch describes "how" you're trying to achieve it, but "what" you
>> ??? want to achieve. I'll get later into why I think the "how" is
>> ??? fundamentally flawed.
>>
>> The 'what' is basically this: I want to be able to parse the fit 
>> header for correctness before
>> any image loading takes place. This 'correctness' will be user defined
>
> I'd expect such code to be part of this series. Having a function that 
> a "user" might define sounds a lot like a vendor-specific hook with no 
> upstream code, hence the skepticism. This series should include a 
> useful implementation of board_spl_fit_pre_load().
>
>
>> ??The main use case for us is two folds:
>> (1) Customers are worried about our reliance on libfdt for FIT 
>> parsing and want to prescan the FIT header to
>> check for any future exploits
>> (2) We implement a signature on the entire FIT header ( instead of 
>> individual nodes ).
>
> Do you believe the current FIT signing scheme is inappropriate for 
> your needs? Have you looked at signed configs? Is there a reason why 
> they are not appropriate?
>
> There was a potential issue where a bad FIT could place itself 
> anywhere in memory. This was fixed in commit 03f1f78a9b ("spl: fit: 
> Prefer a malloc()'d buffer for loading images"). Keep in mind that, in 
> this case, checking the FIT header would not have guarded against the 
> exploit.
>

I reach the same issue, my customers are also worried with the actual 
signature check scheme on u-boot.
The fit data/node are parsed before being checked : data should be used 
only after being checked, not before.
The code become quite complex for a signature, and the more complex the 
code is more risk to have/introduce a bug or security issue.



>
>> ??? Second issue is that spl_simple_fit_read() is intended to bring a 
>> FIT
>> ??? image to memory. If you need to make decisions on the content of 
>> that
>> ??? image, then spl_simple_fit_read() is the wrong place to do it. A 
>> better
>> ??? place might be spl_simple_fit_parse().
>>
>> spl_simple_fit_parse()? parses the 'contents' of the fit using 
>> standard APIs. We need to check
>> the FIT header for correctness BEFORE its contents are parsed, using 
>> a user defined 'safe'
>> parsing function. The standard FIT loading flow checks for only a few 
>> things ( hashes/configuration etc),
>> there can be a lot of other USER defined checks which may need to be 
>> checked. This callback will achieve this
>
> This patch is calling board_spl_fit_pre_load() after the FIT is read. 
> On a FIT with embedded data, you've also loaded all the binaries. It 
> seems that checking a header now is a moot point.
>
> If you need to make sure that the FIT wasn't tampered, the signed 
> configs were designed exactly for that. You mentioned earlier that you 
> want to sign the FIT header. What is the FIT header in this case? Is 
> it the FDT of a FIT with external data? Is it struct fdt_header?
>

As mentioned above, we (my company and my customer) thought that the fit 
node should only be used after the fit signature is verified (and OK).

>
>> The reason I used a weak function was to mirror the already 
>> upstreamed?board_spl_fit_post_load(),
>
> I see why you'd think it was a good idea. board_spl_fit_pre_load() 
> sneaks in a dependency on arch-specific code (CONFIG_IMX_HAB). I don't 
> really like the way it's implemented, and I don't know if it would 
> work with SPL_LOAD_FIT_FULL or bootm.
>

As I reach the same issue, I was also thinking strongly about adding a 
"hook" before the fit image is launched/analyzed. In my mind this "pre 
load" function should be able to do some check/update to the fit image, 
but also modify the beginning of the fit image (to remove a header for 
example). Such function/feature may allow to:
- check a signature for the full fit (without parsing the node)
- cipher the full fit (even the node)
- compress the full fit
- probably that users will find a lot of others ideas .....

I think that this feature pre load should be implemented in spl and 
bootm command.

I have understood the feedback about a useful implementation/usage of 
pre_load.
I propose to sent an example soon (probably based on signature check).


Regards,

Philippe



> Alex

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
  2021-03-22 14:27         ` Philippe REYNES
@ 2021-03-22 15:12           ` Alex G.
  2021-03-23  0:56             ` Simon Glass
  0 siblings, 1 reply; 12+ messages in thread
From: Alex G. @ 2021-03-22 15:12 UTC (permalink / raw)
  To: u-boot

On 3/22/21 9:27 AM, Philippe REYNES wrote:
> Hi all,
> 
> 
> Le 11/03/2021 ? 00:10, Alex G a ?crit?:
[snip]
> 
> I reach the same issue, my customers are also worried with the actual 
> signature check scheme on u-boot.
> The fit data/node are parsed before being checked : data should be used 
> only after being checked, not before.
> The code become quite complex for a signature, and the more complex the 
> code is more risk to have/introduce a bug or security issue.

[snip]

>>> The reason I used a weak function was to mirror the already 
>>> upstreamed?board_spl_fit_post_load(),
>>
>> I see why you'd think it was a good idea. board_spl_fit_pre_load() 
>> sneaks in a dependency on arch-specific code (CONFIG_IMX_HAB). I don't 
>> really like the way it's implemented, and I don't know if it would 
>> work with SPL_LOAD_FIT_FULL or bootm.
>>
> 
> As I reach the same issue, I was also thinking strongly about adding a 
> "hook" before the fit image is launched/analyzed. In my mind this "pre 
> load" function should be able to do some check/update to the fit image, 
> but also modify the beginning of the fit image (to remove a header for 
> example). Such function/feature may allow to:
> - check a signature for the full fit (without parsing the node)
> - cipher the full fit (even the node)
> - compress the full fit
> - probably that users will find a lot of others ideas .....
> 
> I think that this feature pre load should be implemented in spl and 
> bootm command.
> 
> I have understood the feedback about a useful implementation/usage of 
> pre_load.
> I propose to sent an example soon (probably based on signature check).

So "what" you want to do is verify untrusted metadata before using it. 
That's a very logical and reasonable thing to do.

"How" you are trying to do this is by
  (1) adding a weak function
  (2) allowing each board to have a completely different implementation

Those are two terrible ideas.

I agree that there is a deficiency in the way FIT images are signed. Can 
we stick the signature between the fdt_header and before dt_struct?

Alex

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
  2021-03-22 15:12           ` Alex G.
@ 2021-03-23  0:56             ` Simon Glass
  2021-03-23 17:16               ` Philippe REYNES
  0 siblings, 1 reply; 12+ messages in thread
From: Simon Glass @ 2021-03-23  0:56 UTC (permalink / raw)
  To: u-boot

Hi Alex,

On Tue, 23 Mar 2021 at 04:12, Alex G. <mr.nuke.me@gmail.com> wrote:
>
> On 3/22/21 9:27 AM, Philippe REYNES wrote:
> > Hi all,
> >
> >
> > Le 11/03/2021 ? 00:10, Alex G a ?crit :
> [snip]
> >
> > I reach the same issue, my customers are also worried with the actual
> > signature check scheme on u-boot.
> > The fit data/node are parsed before being checked : data should be used
> > only after being checked, not before.
> > The code become quite complex for a signature, and the more complex the
> > code is more risk to have/introduce a bug or security issue.
>
> [snip]
>
> >>> The reason I used a weak function was to mirror the already
> >>> upstreamed board_spl_fit_post_load(),
> >>
> >> I see why you'd think it was a good idea. board_spl_fit_pre_load()
> >> sneaks in a dependency on arch-specific code (CONFIG_IMX_HAB). I don't
> >> really like the way it's implemented, and I don't know if it would
> >> work with SPL_LOAD_FIT_FULL or bootm.
> >>
> >
> > As I reach the same issue, I was also thinking strongly about adding a
> > "hook" before the fit image is launched/analyzed. In my mind this "pre
> > load" function should be able to do some check/update to the fit image,
> > but also modify the beginning of the fit image (to remove a header for
> > example). Such function/feature may allow to:
> > - check a signature for the full fit (without parsing the node)
> > - cipher the full fit (even the node)
> > - compress the full fit
> > - probably that users will find a lot of others ideas .....
> >
> > I think that this feature pre load should be implemented in spl and
> > bootm command.
> >
> > I have understood the feedback about a useful implementation/usage of
> > pre_load.
> > I propose to sent an example soon (probably based on signature check).
>
> So "what" you want to do is verify untrusted metadata before using it.
> That's a very logical and reasonable thing to do.
>
> "How" you are trying to do this is by
>   (1) adding a weak function
>   (2) allowing each board to have a completely different implementation
>
> Those are two terrible ideas.
>
> I agree that there is a deficiency in the way FIT images are signed. Can
> we stick the signature between the fdt_header and before dt_struct?

That seems like a reasonable idea to me. Even better might be to have
it completely separate, e.g. before the FIT starts, so no parsing at
all is needed?

Also, which signature? FIT supports multiple signatures which can be
added at different times. Perhaps this could be for a base signature,
enough to get through to verifying the 'real' signature.

Regards,
Simon

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
  2021-03-23  0:56             ` Simon Glass
@ 2021-03-23 17:16               ` Philippe REYNES
  2021-03-24  7:09                 ` Simon Glass
  0 siblings, 1 reply; 12+ messages in thread
From: Philippe REYNES @ 2021-03-23 17:16 UTC (permalink / raw)
  To: u-boot

Hi Simon and Alex,

Le 23/03/2021 ? 01:56, Simon Glass a ?crit?:
> Hi Alex,
>
> On Tue, 23 Mar 2021 at 04:12, Alex G. <mr.nuke.me@gmail.com> wrote:
>> On 3/22/21 9:27 AM, Philippe REYNES wrote:
>>> Hi all,
>>>
>>>
>>> Le 11/03/2021 ? 00:10, Alex G a ?crit :
>> [snip]
>>> I reach the same issue, my customers are also worried with the actual
>>> signature check scheme on u-boot.
>>> The fit data/node are parsed before being checked : data should be used
>>> only after being checked, not before.
>>> The code become quite complex for a signature, and the more complex the
>>> code is more risk to have/introduce a bug or security issue.
>> [snip]
>>
>>>>> The reason I used a weak function was to mirror the already
>>>>> upstreamed board_spl_fit_post_load(),
>>>> I see why you'd think it was a good idea. board_spl_fit_pre_load()
>>>> sneaks in a dependency on arch-specific code (CONFIG_IMX_HAB). I don't
>>>> really like the way it's implemented, and I don't know if it would
>>>> work with SPL_LOAD_FIT_FULL or bootm.
>>>>
>>> As I reach the same issue, I was also thinking strongly about adding a
>>> "hook" before the fit image is launched/analyzed. In my mind this "pre
>>> load" function should be able to do some check/update to the fit image,
>>> but also modify the beginning of the fit image (to remove a header for
>>> example). Such function/feature may allow to:
>>> - check a signature for the full fit (without parsing the node)
>>> - cipher the full fit (even the node)
>>> - compress the full fit
>>> - probably that users will find a lot of others ideas .....
>>>
>>> I think that this feature pre load should be implemented in spl and
>>> bootm command.
>>>
>>> I have understood the feedback about a useful implementation/usage of
>>> pre_load.
>>> I propose to sent an example soon (probably based on signature check).
>> So "what" you want to do is verify untrusted metadata before using it.
>> That's a very logical and reasonable thing to do.
>>
>> "How" you are trying to do this is by
>>    (1) adding a weak function
>>    (2) allowing each board to have a completely different implementation
>>
>> Those are two terrible ideas.
>>
>> I agree that there is a deficiency in the way FIT images are signed. Can
>> we stick the signature between the fdt_header and before dt_struct?
> That seems like a reasonable idea to me. Even better might be to have
> it completely separate, e.g. before the FIT starts, so no parsing at
> all is needed?


That's my idea, a header with only the minimum information (like fit 
size and signature).
The information about the signature (hash, algo, padding, public key, 
...) may be stored
in the u-boot device tree. So u-boot won't parse the fit image, only 
compute the hash
to check the signature.

>
> Also, which signature? FIT supports multiple signatures which can be
> added at different times. Perhaps this could be for a base signature,
> enough to get through to verifying the 'real' signature.


I was thinking that the signature information could be stored in the 
u-boot device tree
(or hardcoded in the u-boot configuration). The idea is to have a very 
simple header.
I also think that this signature may be used with the signature in the 
fit.? It is two
options, so users may eanble both options.

As we agree on the principle, I will sent a RFC asap.

> Regards,
> Simon


Regards,
Philippe

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
  2021-03-23 17:16               ` Philippe REYNES
@ 2021-03-24  7:09                 ` Simon Glass
  2021-03-29 23:10                   ` Farhan Ali
  0 siblings, 1 reply; 12+ messages in thread
From: Simon Glass @ 2021-03-24  7:09 UTC (permalink / raw)
  To: u-boot

Hi Philippe,

On Wed, 24 Mar 2021 at 06:16, Philippe REYNES
<philippe.reynes@softathome.com> wrote:
>
> Hi Simon and Alex,
>
> Le 23/03/2021 ? 01:56, Simon Glass a ?crit :
> > Hi Alex,
> >
> > On Tue, 23 Mar 2021 at 04:12, Alex G. <mr.nuke.me@gmail.com> wrote:
> >> On 3/22/21 9:27 AM, Philippe REYNES wrote:
> >>> Hi all,
> >>>
> >>>
> >>> Le 11/03/2021 ? 00:10, Alex G a ?crit :
> >> [snip]
> >>> I reach the same issue, my customers are also worried with the actual
> >>> signature check scheme on u-boot.
> >>> The fit data/node are parsed before being checked : data should be used
> >>> only after being checked, not before.
> >>> The code become quite complex for a signature, and the more complex the
> >>> code is more risk to have/introduce a bug or security issue.
> >> [snip]
> >>
> >>>>> The reason I used a weak function was to mirror the already
> >>>>> upstreamed board_spl_fit_post_load(),
> >>>> I see why you'd think it was a good idea. board_spl_fit_pre_load()
> >>>> sneaks in a dependency on arch-specific code (CONFIG_IMX_HAB). I don't
> >>>> really like the way it's implemented, and I don't know if it would
> >>>> work with SPL_LOAD_FIT_FULL or bootm.
> >>>>
> >>> As I reach the same issue, I was also thinking strongly about adding a
> >>> "hook" before the fit image is launched/analyzed. In my mind this "pre
> >>> load" function should be able to do some check/update to the fit image,
> >>> but also modify the beginning of the fit image (to remove a header for
> >>> example). Such function/feature may allow to:
> >>> - check a signature for the full fit (without parsing the node)
> >>> - cipher the full fit (even the node)
> >>> - compress the full fit
> >>> - probably that users will find a lot of others ideas .....
> >>>
> >>> I think that this feature pre load should be implemented in spl and
> >>> bootm command.
> >>>
> >>> I have understood the feedback about a useful implementation/usage of
> >>> pre_load.
> >>> I propose to sent an example soon (probably based on signature check).
> >> So "what" you want to do is verify untrusted metadata before using it.
> >> That's a very logical and reasonable thing to do.
> >>
> >> "How" you are trying to do this is by
> >>    (1) adding a weak function
> >>    (2) allowing each board to have a completely different implementation
> >>
> >> Those are two terrible ideas.
> >>
> >> I agree that there is a deficiency in the way FIT images are signed. Can
> >> we stick the signature between the fdt_header and before dt_struct?
> > That seems like a reasonable idea to me. Even better might be to have
> > it completely separate, e.g. before the FIT starts, so no parsing at
> > all is needed?
>
>
> That's my idea, a header with only the minimum information (like fit
> size and signature).
> The information about the signature (hash, algo, padding, public key,
> ...) may be stored
> in the u-boot device tree. So u-boot won't parse the fit image, only
> compute the hash
> to check the signature.
>
> >
> > Also, which signature? FIT supports multiple signatures which can be
> > added at different times. Perhaps this could be for a base signature,
> > enough to get through to verifying the 'real' signature.
>
>
> I was thinking that the signature information could be stored in the
> u-boot device tree
> (or hardcoded in the u-boot configuration). The idea is to have a very
> simple header.
> I also think that this signature may be used with the signature in the
> fit.  It is two
> options, so users may eanble both options.
>
> As we agree on the principle, I will sent a RFC asap.

You can store the public key (or whatever is used) in the U-Boot
devicetree, but the signature presumably has to be attached to the
FIT, right?

Regards,
Simon

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
  2021-03-24  7:09                 ` Simon Glass
@ 2021-03-29 23:10                   ` Farhan Ali
  2021-03-30 16:32                     ` Philippe REYNES
  0 siblings, 1 reply; 12+ messages in thread
From: Farhan Ali @ 2021-03-29 23:10 UTC (permalink / raw)
  To: u-boot

Phillipe,

In our implementation we store our binaries outside the FIT header, and
introduce a gap between the header and the start of binary data (-p and -E
option in mkimage). After the FIT has been generated, we sign the FIT
header and insert the signature into this gap. The weak function then
checks the signature after 'only' the header has been loaded, but before
any of the FIT fields have been parsed.

Whatever common implementation we decide on, it is imperative that the
signature can be inserted 'AFTER' the complete FIT has been generated. The
reason this is so critical is to allow for off-line signing via customer
HSMs.

Regards,
Farhan

On Wed, Mar 24, 2021 at 12:09 AM Simon Glass <sjg@chromium.org> wrote:

> Hi Philippe,
>
> On Wed, 24 Mar 2021 at 06:16, Philippe REYNES
> <philippe.reynes@softathome.com> wrote:
> >
> > Hi Simon and Alex,
> >
> > Le 23/03/2021 ? 01:56, Simon Glass a ?crit :
> > > Hi Alex,
> > >
> > > On Tue, 23 Mar 2021 at 04:12, Alex G. <mr.nuke.me@gmail.com> wrote:
> > >> On 3/22/21 9:27 AM, Philippe REYNES wrote:
> > >>> Hi all,
> > >>>
> > >>>
> > >>> Le 11/03/2021 ? 00:10, Alex G a ?crit :
> > >> [snip]
> > >>> I reach the same issue, my customers are also worried with the actual
> > >>> signature check scheme on u-boot.
> > >>> The fit data/node are parsed before being checked : data should be
> used
> > >>> only after being checked, not before.
> > >>> The code become quite complex for a signature, and the more complex
> the
> > >>> code is more risk to have/introduce a bug or security issue.
> > >> [snip]
> > >>
> > >>>>> The reason I used a weak function was to mirror the already
> > >>>>> upstreamed board_spl_fit_post_load(),
> > >>>> I see why you'd think it was a good idea. board_spl_fit_pre_load()
> > >>>> sneaks in a dependency on arch-specific code (CONFIG_IMX_HAB). I
> don't
> > >>>> really like the way it's implemented, and I don't know if it would
> > >>>> work with SPL_LOAD_FIT_FULL or bootm.
> > >>>>
> > >>> As I reach the same issue, I was also thinking strongly about adding
> a
> > >>> "hook" before the fit image is launched/analyzed. In my mind this
> "pre
> > >>> load" function should be able to do some check/update to the fit
> image,
> > >>> but also modify the beginning of the fit image (to remove a header
> for
> > >>> example). Such function/feature may allow to:
> > >>> - check a signature for the full fit (without parsing the node)
> > >>> - cipher the full fit (even the node)
> > >>> - compress the full fit
> > >>> - probably that users will find a lot of others ideas .....
> > >>>
> > >>> I think that this feature pre load should be implemented in spl and
> > >>> bootm command.
> > >>>
> > >>> I have understood the feedback about a useful implementation/usage of
> > >>> pre_load.
> > >>> I propose to sent an example soon (probably based on signature
> check).
> > >> So "what" you want to do is verify untrusted metadata before using it.
> > >> That's a very logical and reasonable thing to do.
> > >>
> > >> "How" you are trying to do this is by
> > >>    (1) adding a weak function
> > >>    (2) allowing each board to have a completely different
> implementation
> > >>
> > >> Those are two terrible ideas.
> > >>
> > >> I agree that there is a deficiency in the way FIT images are signed.
> Can
> > >> we stick the signature between the fdt_header and before dt_struct?
> > > That seems like a reasonable idea to me. Even better might be to have
> > > it completely separate, e.g. before the FIT starts, so no parsing at
> > > all is needed?
> >
> >
> > That's my idea, a header with only the minimum information (like fit
> > size and signature).
> > The information about the signature (hash, algo, padding, public key,
> > ...) may be stored
> > in the u-boot device tree. So u-boot won't parse the fit image, only
> > compute the hash
> > to check the signature.
> >
> > >
> > > Also, which signature? FIT supports multiple signatures which can be
> > > added at different times. Perhaps this could be for a base signature,
> > > enough to get through to verifying the 'real' signature.
> >
> >
> > I was thinking that the signature information could be stored in the
> > u-boot device tree
> > (or hardcoded in the u-boot configuration). The idea is to have a very
> > simple header.
> > I also think that this signature may be used with the signature in the
> > fit.  It is two
> > options, so users may eanble both options.
> >
> > As we agree on the principle, I will sent a RFC asap.
>
> You can store the public key (or whatever is used) in the U-Boot
> devicetree, but the signature presumably has to be attached to the
> FIT, right?
>
> Regards,
> Simon
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210329/41bbd525/attachment.bin>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
  2021-03-29 23:10                   ` Farhan Ali
@ 2021-03-30 16:32                     ` Philippe REYNES
  0 siblings, 0 replies; 12+ messages in thread
From: Philippe REYNES @ 2021-03-30 16:32 UTC (permalink / raw)
  To: u-boot

Hi Farhan,

Le 30/03/2021 ? 01:10, Farhan Ali a ?crit?:
> Phillipe,
>
> In our implementation?we store?our binaries outside the FIT header, 
> and introduce a gap between the header and the start of binary data 
> (-p and -E option in mkimage). After the FIT has been generated, we 
> sign the FIT header and insert the signature into this gap. The weak 
> function then checks the signature after 'only' the header has been 
> loaded, but before any of the FIT fields have been parsed.
>
> Whatever common implementation we decide on, it is imperative that the 
> signature can be inserted 'AFTER' the complete FIT has been generated. 
> The reason this is so critical?is to allow for off-line signing via 
> customer HSMs.
>
I think we are in line. I just sent a patch that add a stage pre-load to 
the command bootm.
The idea is to add a header to the fit image with:
- a magic : to check that it is a header with a signature
- the size of the image : to know what size should be checked
- the size of the signature
- the signature
All others information are in the u-boot device (header size, public 
key, ...), so the header is minimal.
I think that his "header" is compatible with the patch you have sent.

I? also plan to support multiple cascaded headers. So we could also 
cipher the full fit, or compress the full fit, or any other idea ...


> Regards,
> Farhan
>

Best regards,
Philippe


> On Wed, Mar 24, 2021 at 12:09 AM Simon Glass <sjg@chromium.org 
> <mailto:sjg@chromium.org>> wrote:
>
>     Hi Philippe,
>
>     On Wed, 24 Mar 2021 at 06:16, Philippe REYNES
>     <philippe.reynes@softathome.com
>     <mailto:philippe.reynes@softathome.com>> wrote:
>     >
>     > Hi Simon and Alex,
>     >
>     > Le 23/03/2021 ? 01:56, Simon Glass a ?crit :
>     > > Hi Alex,
>     > >
>     > > On Tue, 23 Mar 2021 at 04:12, Alex G. <mr.nuke.me@gmail.com
>     <mailto:mr.nuke.me@gmail.com>> wrote:
>     > >> On 3/22/21 9:27 AM, Philippe REYNES wrote:
>     > >>> Hi all,
>     > >>>
>     > >>>
>     > >>> Le 11/03/2021 ? 00:10, Alex G a ?crit :
>     > >> [snip]
>     > >>> I reach the same issue, my customers are also worried with
>     the actual
>     > >>> signature check scheme on u-boot.
>     > >>> The fit data/node are parsed before being checked : data
>     should be used
>     > >>> only after being checked, not before.
>     > >>> The code become quite complex for a signature, and the more
>     complex the
>     > >>> code is more risk to have/introduce a bug or security issue.
>     > >> [snip]
>     > >>
>     > >>>>> The reason I used a weak function was to mirror the already
>     > >>>>> upstreamed board_spl_fit_post_load(),
>     > >>>> I see why you'd think it was a good idea.
>     board_spl_fit_pre_load()
>     > >>>> sneaks in a dependency on arch-specific code
>     (CONFIG_IMX_HAB). I don't
>     > >>>> really like the way it's implemented, and I don't know if
>     it would
>     > >>>> work with SPL_LOAD_FIT_FULL or bootm.
>     > >>>>
>     > >>> As I reach the same issue, I was also thinking strongly
>     about adding a
>     > >>> "hook" before the fit image is launched/analyzed. In my mind
>     this "pre
>     > >>> load" function should be able to do some check/update to the
>     fit image,
>     > >>> but also modify the beginning of the fit image (to remove a
>     header for
>     > >>> example). Such function/feature may allow to:
>     > >>> - check a signature for the full fit (without parsing the node)
>     > >>> - cipher the full fit (even the node)
>     > >>> - compress the full fit
>     > >>> - probably that users will find a lot of others ideas .....
>     > >>>
>     > >>> I think that this feature pre load should be implemented in
>     spl and
>     > >>> bootm command.
>     > >>>
>     > >>> I have understood the feedback about a useful
>     implementation/usage of
>     > >>> pre_load.
>     > >>> I propose to sent an example soon (probably based on
>     signature check).
>     > >> So "what" you want to do is verify untrusted metadata before
>     using it.
>     > >> That's a very logical and reasonable thing to do.
>     > >>
>     > >> "How" you are trying to do this is by
>     > >>? ? (1) adding a weak function
>     > >>? ? (2) allowing each board to have a completely different
>     implementation
>     > >>
>     > >> Those are two terrible ideas.
>     > >>
>     > >> I agree that there is a deficiency in the way FIT images are
>     signed. Can
>     > >> we stick the signature between the fdt_header and before
>     dt_struct?
>     > > That seems like a reasonable idea to me. Even better might be
>     to have
>     > > it completely separate, e.g. before the FIT starts, so no
>     parsing at
>     > > all is needed?
>     >
>     >
>     > That's my idea, a header with only the minimum information (like fit
>     > size and signature).
>     > The information about the signature (hash, algo, padding, public
>     key,
>     > ...) may be stored
>     > in the u-boot device tree. So u-boot won't parse the fit image, only
>     > compute the hash
>     > to check the signature.
>     >
>     > >
>     > > Also, which signature? FIT supports multiple signatures which
>     can be
>     > > added at different times. Perhaps this could be for a base
>     signature,
>     > > enough to get through to verifying the 'real' signature.
>     >
>     >
>     > I was thinking that the signature information could be stored in the
>     > u-boot device tree
>     > (or hardcoded in the u-boot configuration). The idea is to have
>     a very
>     > simple header.
>     > I also think that this signature may be used with the signature
>     in the
>     > fit.? It is two
>     > options, so users may eanble both options.
>     >
>     > As we agree on the principle, I will sent a RFC asap.
>
>     You can store the public key (or whatever is used) in the U-Boot
>     devicetree, but the signature presumably has to be attached to the
>     FIT, right?
>
>     Regards,
>     Simon
>

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2021-03-30 16:32 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-24 23:25 [PATCH] spl: Add callback for preprocessing loaded FIT header before parsing Farhan Ali
2021-03-09 23:55 ` [PATCH v2] " Farhan Ali
2021-03-10 19:38   ` Alex G.
2021-03-10 20:49     ` Farhan Ali
2021-03-10 23:10       ` Alex G
2021-03-22 14:27         ` Philippe REYNES
2021-03-22 15:12           ` Alex G.
2021-03-23  0:56             ` Simon Glass
2021-03-23 17:16               ` Philippe REYNES
2021-03-24  7:09                 ` Simon Glass
2021-03-29 23:10                   ` Farhan Ali
2021-03-30 16:32                     ` Philippe REYNES

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.