Hi, On Thu, Jun 2, 2022 at 9:50 AM Jerome Forissier <jerome.foriss...@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