All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe REYNES <philippe.reynes@softathome.com>
To: u-boot@lists.denx.de
Subject: [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
Date: Mon, 22 Mar 2021 15:27:34 +0100	[thread overview]
Message-ID: <389855fe-9401-83b6-350f-eb453ab214ae@softathome.com> (raw)
In-Reply-To: <af118ca7-2bda-e91a-9a54-84ecb4d39e1a@gmail.com>

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

  reply	other threads:[~2021-03-22 14:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=389855fe-9401-83b6-350f-eb453ab214ae@softathome.com \
    --to=philippe.reynes@softathome.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.