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

[Jerome Forissier]

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.

-- 
Jerome