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_lop_addr = e_entryp_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?