[PATCH] mach-rockchip: make_fit_atf.py: support OP-TEE tee.bin v1 format

[Jens Wiklander]

Hi,

On Thu, Jun 2, 2022 at 9:50 AM Jerome Forissier
<jerome.forissier at linaro.org> wrote:
>
>
>
> On 5/29/22 18:08, Alper Nebi Yasak wrote:
> > On 28/05/2022 01:08, Jerome Forissier wrote:
> >> On 5/27/22 21:24, Alper Nebi Yasak wrote:
> >>> On 11/05/2022 18:35, Jerome Forissier wrote:
> >>>> +        if paged_sz != 0:
> >>>> +            raise ValueError("OP-TEE paged mode not supported")
> >>>
> >>> Is this not feasible/necessary to do, or just not implemented yet?
> >>
> >> Just not implemented yet. Pager support is not strictly needed, its use or not
> >> depends on the platform and on the threat model. In other words, whether or not
> >> it is OK to have the TEE and TAs run in DRAM, usually isolated only from Normal
> >> World software by TrustZone or some kind of memory firewall. Pager allows to
> >> protect from physical access to the DRAM too. It provides authentication and/or
> >> encryption to anything stored outside the internal SRAM of the SoC.
> >> Testing this mode on RockPi4 would require some non trivial work. Here I simply
> >> focused on implementing the current use case properly.
> >
> > I assume you mean it would need platform-specific work on the OP-TEE OS
> > side.
>
> Yes.
>  > But let me ask in a general sense, would we need to pass
> > 'paged_size', 'init_mem_usage', etc. via the FIT to U-Boot? Or, how well
> > does the info in the files and headers (v1 and v2) map to FIT images and
> > their properties?
>
> Yes, the parameters in the tee.bin header would tell U-Boot if the binary needs to
> be split in two parts (paged_size != 0) or not. The load address of the "non paged"
> part is also in the header. And, when a "paged" part is present its load address
> has to be passed to OP-TEE via register x1.
>
> > Why I am asking these is that I'm hypothesizing we can put the
> > unmodified 'tee.bin' (including header) and 'bl31.elf' (normally split
> > into raw binary pieces) into the FIT, and then interpret them at runtime
> > on the C side. Trying to figure out if it's a good idea.
>
> Definitely sounds doable. It could help having more common code perhaps, and also
> simplify the content of the FIT and therefore the verification of hash and
> signatures.
>
> >>>> +        e_entry = (start_hi << 32) + start_lo
> >>>> +        p_addr = e_entry
> >>>> +        p_data = bin[0x1c:]
> >>>> +        if len(p_data) != init_sz:
> >>>> +            raise ValueError("Invalid file '%s': size mismatch "
> >>>> +                             "(expected %d, have %d)" % (filename, init_sz,
> >>>> +                                                         len(p_data)))
> >>>> +        segments.append((0, e_entry, p_addr, p_data))
> >>>> +    else:
> >>>> +        raise ValueError("Unknown format for TEE file '%s'" % filename)
> >>>
> >>> I see an 'output_header_v2' in your link [2], what about that?
> >>
> >> v2 is useful only when the OP-TEE pager is used, in which case it is a matter
> >> of preference whether to use a single binary and have the loader split it as
> >> expected (tee.bin) or use separate binaries instead.
> >>
> >> Historically (Jens please correct me if I'm wrong!), there was a single raw
> >> binary for OP-TEE: tee.bin, and no pager support. Then pager was added. The
> >> build would then create two separate files: tee-pager.bin and tee-pageable.bin
> >> (the latter would be zero sized with pager disabled). At the same time a header
> >> was introduced in tee.bin to indicate whether or not the file would contain a
> >> pageable section (tee.bin consisted in the header + tee-pager.bin +
> >> tee-pageable.bin). Later, and for reasons I don't remember exactly (related to
> >> the integration with TF-A IIRC), the header was written to its own file and the
> >> format of that header changed a bit. So we had tee-header_v2.bin,
> >> tee-pager_v2.bin, and tee-pageable_v2.bin. The previous tee-pager.bin and
> >> tee-pageable.bin were subsequently deprecated; but tee.bin wasn't. It is still
> >> generated today, unchanged with its "v1" header. Note, I'm not sure if
> >> tee-pager_v2.bin is different from tee-pager.bin (and same goes for the
> >> pageable part), but it doesn't really matter for this discussion.
> >
> > Thanks for both explanations. I also kept looking at gen_tee_bin.py and
> >  outputs from a few OP-TEE OS builds. If I got things right, I can do:
> >
> >   cat tee-header_v2.bin tee-pager_v2.bin tee-pageable_v2.bin >tee_v2.bin
> >
> > and that would effectively be the same kind of file/image as tee.bin,
> > just with a v2 header instead of v1, right?
>
> Correct.

It could be worth checking how TF-A loads OP-TEE. The relevant code is
in https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/optee/optee_utils.c

Cheers,
Jens