All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
Date: Tue, 23 Mar 2021 13:56:56 +1300	[thread overview]
Message-ID: <CAPnjgZ3co5FuPZZ9eZOrygAg+CmauDjD1oU+GXe14h9d9h_1PQ@mail.gmail.com> (raw)
In-Reply-To: <96f54554-b201-12c4-287b-794efaff19e9@gmail.com>

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

  reply	other threads:[~2021-03-23  0:56 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
2021-03-22 15:12           ` Alex G.
2021-03-23  0:56             ` Simon Glass [this message]
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=CAPnjgZ3co5FuPZZ9eZOrygAg+CmauDjD1oU+GXe14h9d9h_1PQ@mail.gmail.com \
    --to=sjg@chromium.org \
    --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.