From mboxrd@z Thu Jan  1 00:00:00 1970
From: Patrick Oppenlander <patrick.oppenlander@gmail.com>
Date: Thu, 30 Jul 2020 11:19:03 +1000
Subject: [PATCH 2/3] mkimage: fit: handle FDT_ERR_NOSPACE when ciphering
In-Reply-To: <211440822.525164.1596034958219.JavaMail.zimbra@softathome.com>
References: <20200717072825.371105-1-patrick.oppenlander@gmail.com>
 <20200717072825.371105-2-patrick.oppenlander@gmail.com>
 <211440822.525164.1596034958219.JavaMail.zimbra@softathome.com>
Message-ID: <CAEg67Gm0ehM2YR+744geNumDiUfOcqoyiF7xtF73mXZL8XiSpg@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Thu, Jul 30, 2020 at 1:02 AM Philippe REYNES
<philippe.reynes@softathome.com> wrote:
>
> Hi Patrick
>
> > From: Patrick Oppenlander <patrick.oppenlander@gmail.com>
> >
> > This meant that the order of operations had to change. If we replace the
> > data property first then fail to add the data-size-unciphered property
> > the data will be ciphered again when retrying.
>
>
> This patch is good, but I disagree with the comment. It is not mandatory
> to change the order of operation because when signing/ciphering we always
> start from "fresh" file.
>
> This "trick" is done in the function fit_handle_file(...)
>
> Just before the loop, the tmpfile is rename in bakfile
>
>         sprintf(bakfile, "%s%s", tmpfile, ".bak");
>         rename(tmpfile, bakfile);
>
> And in the loop, the first operation is to copy bakfile to tmpfile:
>
>         for (size_inc = 0; size_inc < 64 * 1024; size_inc += 1024) {
>                 if (copyfile(bakfile, tmpfile) < 0) {
>                         printf("Can't copy %s to %s\n", bakfile, tmpfile);
>                         ret = -EIO;
>                         break;
>                 }
>                 ret = fit_add_file_data(params, size_inc, tmpfile);
>                 if (!ret || ret != -ENOSPC)
>                         break;
>         }
>
> So I think that we always cipher with unciphered data.
>

Hi Philip,

I don't think that is the case if you use "mkimage -F". The input can
already be ciphered.

Patrick