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

[Alper Nebi Yasak]

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. 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?

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.

>>> +        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?