[PATCH] spl: Add callback for preprocessing loaded FIT header before parsing
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; }
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)
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)
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 loadingbinaries */
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)
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
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
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
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
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
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
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
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
participants (5)
-
Alex G -
Alex G.
-
Farhan Ali -
Philippe REYNES -
Simon Glass