Can static TA Open/Invoke dynamic TA?

[Yanjiong]

Hi,

Can static TA Open/Invoke dynamic TA?

BR.
Wang Yanjiong

[jenswi-linaro]

Yes, but it's more work than just calling a function.

[Yanjiong]

Like to do the things which did in syscall_open_ta_session/syscall_invoke_ta_command/syscall_close_ta_session?

Static TA should run in user space right? Could it be linked to libutee to call tee api?

[vchong]

Static TAs run in kernel space and are compiled as part of optee_os, so you should be able to call functions within the optee_os core.

[Yanjiong]

So I should implement some api funcs similar with syscall_open_ta_session/syscall_invoke_ta_command/syscall_close_ta_session to be used by static TAs.

Any works like this have been done and I can refer to? I think this should be a normal request.

[jenswi-linaro]

This is something new. What does the use case look like (apart from the fact that you want to call a dynamic TA from a static TA)?

[Yanjiong]

Like dynamic TA providing some service to other TAs (dynamic or static) and the static TAs act as the client of the service.

[jenswi-linaro]

But why? A static TA is just an interface, it's not a TA per se.

[Yanjiong]

What does "static TA is just an interface but not a TA" mean? What kind of app suggested to be implemented as static TA?

Thanks.

[jenswi-linaro]

A static TA is a way of exposing special services to dynamic TAs and clients.

[jforissier]

@Yanjiong bear in mind that a static TA is code inside the TEE core. As such, it does not have its own address space and can corrupt the whole TEE if poorly written. Also it is usually more difficult to upgrade that a dynamic (user) TA which is a file in the normal world file system.
On the other hand, the static TA can access the hardware directly by calling any driver code inside the TEE core. This means you may use a static TA to extend the services offered by the Internal API, without adding any new system call.

[Yanjiong]

Got it. Thanks.

One case must implement app as static TA is that when the TA should be launched before REE fs ready. After the REE fs ready and dynamic TAs launched and could providing service to that static TA, there is the need that the static TA want to Open/Invoke to the dynamic TA.

[etienne-lms]

@Yanjiong, you need is to be able to load some platform standard (user) TAs before REE is ready, maybe at boot. I think you need something that could be added to optee.

At build time, one could build some trusted applications (full featured user TAs) and load their images into some binary file. The early bootloader, together with optee image, would load these data in secure memory.

optee core could be booted with this extra image image (through device tree? boot arguments?) and could create execution contextes for the TAs from this extra image even before TEE/REE RPC is available.

This is not available, and not yet planned neither but i think i could be useful.

[vchong]

@Yanjiong can you maybe use the tee-supplicant instead to provide the services?

[etienne-lms]

@vchong. i think the problem is that tee-supplicant is not yet operational when the service is needed.

[vchong]

@etienne-lms understand. Was just wondering if the supplicant can be an alternative for the dynamic TAs where @Yanjiong mentioned that: "After the REE fs ready and dynamic TAs launched and could providing service to that static TA, there is the need that the static TA want to Open/Invoke to the dynamic TA." If yes then static TA doesn't have to worry about opening or invoking the dynamic TA.

[ghost]

We're closing this issue since the question has been answered. If you however feel that you have additional questions or still thinks this is an issue, please feel free to re-open the issue again.