[PATCH v2 14/25] binman: Allow mkimage to use a non-zero fake-blob size

[Simon Glass]

Hi Alper,

On Thu, 10 Mar 2022 at 12:36, Alper Nebi Yasak <alpernebiyasak at gmail.com> wrote:
>
> On 06/03/2022 06:08, Simon Glass wrote:
> > On Thu, 3 Mar 2022 at 14:16, Alper Nebi Yasak <alpernebiyasak at gmail.com> wrote:
> >>>      def ObtainContents(self):
> >>> +        # Use a non-zero size for any fake files to keep mkimage happy
> >>>          data, input_fname, uniq = self.collect_contents_to_file(
> >>> -            self._mkimage_entries.values(), 'mkimage')
> >>> +            self._mkimage_entries.values(), 'mkimage', 1024)
> >>
> >> I kind of want to say that mkimage-the-etype should be able to handle
> >> here whatever it gets from subentries (maybe by writing a single-byte
> >> file itself), and mkimage-the-executable should be able to handle
> >> zero-size files, but I'm not confident in those opinions.
> >
> > Well the entry has no problem with missing files, so that should be OK.
>
> What I meant is when the non-faked input data ends up being zero-sized.
> A bit contrived, but this still triggers the error:
>
>     mkimage {
>         args = ...;
>
>         blob-ext {
>             filename = "/dev/null"; /* or any other zero-size file */
>         };
>     };
>
> which might end up happening e.g. via tee-os with TEE=/dev/null, I
> remember someone doing that for one of the blobs in a mail but can't
> find it or recall any details.

Hmm OK. So long as the error message is useful then we should be OK. I
suspect the /dev/null thing was for when TEE was missing, but binman
handles that differently, so we should not use /dev/null anywhere with
binman.

>
> > For mkimage I agree it is a strange restriction. Perhaps we should
> > just change it? I don't see what problem it could create.
>
> I don't know either.

I suppose one way to find out is to change it!

Regards,
Simon