Can shared library in the secure world communicate with application in the normal world?

[ignorerly]

I'm a beginner of the OP-TEE, I have known that two executable (one in normal world, the other in secure world) could communicate with each other via op-TEE APIs.

My questions are:

1. can we put a shared library which contains several functions in the secure world, then the executable in the normal world to call the functions in the shared library?

2. OP-TEE provides two OS in different world. I was wondering whether there also are two file system in different world. In other word, how can we distinguish which executable is running on normal world or secure world?

Thanks in advance!

[lws-team]

1. Depends what you mean.

OP-TEE has a concept of Trusted Applications (TAs) which are like modules for OP-TEE in secure world. You can implement your functionality in there, and then multiple applications in normal world can use the functionality. TAs are not "shared libraries" though. They are more like kernel modules which implement functionality any user app can access.

If you mean, "can I put another project like BoringSSL inside a TA", yes you can, I have done it, but:

• it is not a .so, you must static link it into the TA

• There are some "libc" exports in OP-TEE for TAs to access, things like [v]snprintf() and so on that are very useful. However the list of available "libc" exports is very small compared to a normal world libc.

Your "library", if it's like BoringSSL or OpenSSL that expects a normal libc available, will use a lot of missing "libc" functions you are responsible to provide inside the TA then. In my case there were initially 91 dangling functions between BoringSSL + Libwebsockets and what was provided in OP-TEE for a TA to link to. I reduced this to minimum needed for the task by disabling things in the libraries, and then provided stubs for the rest so it could link.

Once it could link, meaning you have dummy stubs for every missing import, you have to provide syscalls (in OP-TEE) and RPC handling (in tee-supplicant) for the functions that must be fulfilled in the normal world, and wire your function stubs up to it.

What this means is if your TA "library" like BoringSSL wants to use the Posix socket() api or getaddrinfo() or whatever, it is your responsibility[1] to provide a socket() or getaddrinfo() function inside the TA. Then you must marshal the arguments and pass it by RPC to tee-supplicant in the normal world. In tee-supplicant, you actually call the normal socket() from glibc, and pass back the results through the RPC mechanism.

That isn't trivial (or properly documented) but to give you an idea here are the places need to touch to implement one new syscall / RPC api (files with _atb in there are new files containing my RPCs and related functions)

optee_os

 core/arch/arm/tee/arch_svc.c              |    1 +
 core/include/optee_msg_atb.h              |    3 ++
 core/include/tee/tee_atb_rpc.h            |    3 ++
 core/include/tee/tee_svc_atb.h            |    3 ++
 core/tee/tee_atb_rpc.c                    |   57 +++++++++++++++++++++++++++++
 lib/libutee/arch/arm/utee_syscalls_asm.S  |    4 ++
 lib/libutee/include/tee_api.h             |    2 +
 lib/libutee/include/tee_syscall_numbers.h |    3 +-
 lib/libutee/include/utee_syscalls.h       |    3 ++
 lib/libutee/tee_api_atb.c                 |    6 +++

optee_client

 tee-supplicant/src/tee_supplicant.c |    9 +++++++++

the TA

 passthru.c |   11 ++++++-----

In addition to this, you must implement the normal world RPC handler in optee_client/tee-supplicant.

2. The worlds and their APIs are completely different there is no danger of not knowing what you are running on. There is a "secure filesystem" concept in OP-TEE that allows you to encrypt stuff in the secure world and then give it to tee-supplicant again via RPC for storage and retrieval in the normal world.

[1] OP-TEE is supposed to be growing its own socket() implementation. But it is broken atm, and my patches were ignored, so I rolled my own.

[ignorerly]

Extremely thanks for the help. I think I need to investigate more and try to understand all the details of your answer. Again, thanks a lot!

[ghost]

Thanks for helping out answering the question. 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.