Hi Jerome,

On Fri, 9 Dec 2022 at 06:55, Jerome Forissier
<[email protected]> wrote:
>
>
>
> On 12/9/22 15:24, Quentin Schulz wrote:
> > Hi Simon,
> >
> > On 12/8/22 18:32, Simon Glass wrote:
> >> Hi Xavier,
> >>
> >> On Fri, 9 Dec 2022 at 03:25, Xavier Drudis Ferran <[email protected]> 
> >> wrote:
> >>>
> >>> El Thu, Dec 08, 2022 at 08:56:57AM +1300, Simon Glass deia:
> >>>> +                             @tee-SEQ {
> >>>> +                                     fit,operation = "split-elf";
> >>>> +                                     description = "TEE";
> >>>> +                                     type = "tee";
> >>>> +                                     arch = "arm64";
> >>>> +                                     os = "tee";
> >>>> +                                     compression = "none";
> >>>> +                                     fit,load;
> >>>> +                                     fit,entry;
> >>>> +                                     fit,data;
> >>>> +
> >>>> +                                     tee-os {
> >>>> +                                     };
> >>>> +                             };
> >>>
> >>> I don't know, I may likely have missed something here, but are you sure 
> >>> you're
> >>> taking Jerome into account ?
> >>>
> >>> https://urldefense.com/v3/__https://lists.denx.de/pipermail/u-boot/2022-July/490069.html__;!!OOPJP91ZZw!ltyK0RA-1Vj1dgI1cBlgG1bJOhuZ4JGxwGBIl-Nt-hFz0eZTXmQKALvE9wCKtquDSpexcMtSVjm7ay_Mn7a5e-N4yIc$
> >>> https://urldefense.com/v3/__https://lists.denx.de/pipermail/u-boot/2022-November/499306.html__;!!OOPJP91ZZw!ltyK0RA-1Vj1dgI1cBlgG1bJOhuZ4JGxwGBIl-Nt-hFz0eZTXmQKALvE9wCKtquDSpexcMtSVjm7ay_Mn7a5Y8ANiXk$
> >>
> >> No, I have not done that. The patches mentioned are additions to a
> >> deprecated script!
> >>
> >
> > I think there's a a possible misunderstanding here. I believe Jerome 
> > pointed out that make_fit_atf.py currently supports two formats for the tee 
> > binary and is asking if the implementation you're suggesting take care of 
> > that.
>
> Yes, and I suspect the answer is no ;)
>
> >> It introduces a new binary format which binman needs to decode...
>
> Correct, but this was done to fix an assumption that has never been
> true in the first place: that OP-TEE's tee.elf file could be used
> by bootloaders as the TEE image. It happened to work in the past and it
> may still work depending on config options, but as described in [1],
> the introduction of ASLR broke that assumption. Here I am speaking only
> for OP-TEE, other TEEs may very well be supplied as ELF files of course.
>
> [1] 348310233dac ("mach-rockchip: make_fit_atf.py: support OP-TEE tee.bin v1
> format")
>
> >> that
> >> will need to be added as a new type, I think, since it seems to use
> >> the filename suffix to decide what format it is in.
>
> The suffix is a quick way to tell formats apart but some more precise
> detection code could be used instead if needed (telling if a file is ELF
> or is OP-TEE .bin can done by looking at the header). Or perhaps this
> information should be provided by the user?
>
> > If my aforementioned assumption is correct, that unfortunately would make 
> > this patch series a regression, making it a blocker.
>
> Agreed. Unfortunately I am not familiar *at all* with binman (or u-boot
> in general), so I am not sure how I can help other than with testing. Or
> maybe someone can propose some rough patch and I would insert the missing
> bits? (i.e., parsing the OP-TEE header).

Hmm, OK. I will have to think of a sensible way to add this to binman.

I believe we should start thinking about standard ways to package
these blobs, with the metadata needed to process them. It would be
better than every project adding its own custom binary header IMO.

Regards,
Simon

Reply via email to