> > > > > > > >> 3. The TEE subsystem supports two type of memory sharing: > > >> - per-device memory pools, and > > >> - user defined memory references. > > >> User defined memory references are private to the application and cannot > > >> be shared. Memory allocated from per-device "shared" pools are accessible > > >> using a file descriptor. It can be mapped by any process if it has > > >> access to it. This means, we cannot provide the resource isolation > > >> between two clients. Assume a scenario when a client wants to allocate a > > >> memory (which is shared with TEE) from an "isolated" pool and share it > > >> with another client, without the right to access the contents of memory. > > > > > > This doesn't explain, why would it want to share such memory with > > > another client. > > > > Ok, I believe there is a misunderstanding here. I did not try to justify > > specific usecase. We want to separate the memory allocation from the > > framework. This way, how the memory is obtained, e.g. it is allocated > > (1) from an isolated pool, (2) a shared pool, (3) a secure heap, > > (4) a system dma-heap, (5) process address space, or (6) other memory > > with "different constraints", becomes independent. > > > > We introduced "memory object" type. User implements a kernel service > > using "qcom_tee_object" to represent the memory object. We have an > > implementation of memory objects based on dma-buf. > > I would really like to see use-cases for integration of dma-buf with TEE subsystem. You can see earlier attempt here [1] but without an upstream implementation of secure heap we can't land it upstream. [1] https://lkml.org/lkml/2022/8/12/544 > > > > > >> 4. The kernel API provided by TEE subsystem does not support a kernel > > >> supplicant. Adding support requires an execution context (e.g. a > > >> kernel thread) due to the TEE subsystem design. tee_driver_ops supports > > >> only "send" and "receive" callbacks and to deliver a request, someone > > >> should wait on "receive". > > > > > > There is nothing wrong here, but maybe I'm misunderstanding something. > > > > I agree. But, I am trying to re-emphasize how useful TEE subsystem is > > for MinkIPC. For kernel services, we solely rely on the backend driver. > > For instance, to expose RPMB service we will use "qcom_tee_object". > > So there is nothing provided by the framework to simplify the service > > development. > > OP-TEE has a similar requirement to access RPMB as a kernel supplicant service [1]. Like I said above there is nothing stopping us to extend TEE subsystem with common parts like RPMB kernel service to be reused among backend drivers. [2] https://lore.kernel.org/lkml/20240527121340.3931987-1-jens.wiklander@xxxxxxxxxx/T/ > > > > > >> We need a callback to "dispatch" or "handle" a request in the context of > > >> the client thread. It should redirect a request to a kernel service or > > >> a user supplicant. In TEE subsystem such requirement should be implemented > > >> in TEE back-end driver, independent from the TEE subsystem. > > >> > > >> 5. The UAPI provided by TEE subsystem is similar to the GPTEE Client > > >> interface. This interface is not suitable for a capability system. Have a look at how Trusted Services TEE implementation [3] (non GPTEE compliant) works nicely with TEE subsystem. [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/tee/ts-tee.rst > > >> For instance, there is no session in a capability system which means > > >> either its should not be used, or we should overload its definition. > > > > > > General comment: maybe adding more detailed explanation of how the > > > capabilities are aquired and how they can be used might make sense. > > > > > > BTW. It might be my imperfect English, but each time I see the word > > > 'capability' I'm thinking that some is capable of doing something. I > > > find it hard to use 'capability' for the reference to another object. > > > > > > > Explained at the top :). > > > > >> > > >> Can we use TEE subsystem? > > >> ------------------------- > > >> There are workarounds for some of the issues above. The question is if we > > >> should define our own UAPI or try to use a hack-y way of fitting into > > >> the TEE subsystem. I am using word hack-y, as most of the workaround > > >> involves: > > >> > > >> - "diverging from the definition". For instance, ignoring the session > > >> open and close ioctl calls or use file descriptors for all remote > > >> resources (as, fd is the closet to capability) which undermines the > > >> isolation provided by the contexts, > > >> > > >> - "overloading the variables". For instance, passing object ID as file > > >> descriptors in a place of session ID, or > > >> > > >> - "bypass TEE subsystem". For instance, extensively rely on meta > > >> parameters or push everything (e.g. kernel services) to the back-end > > >> driver, which means leaving almost all TEE subsystem unused. > > >> > > >> We cannot take the full benefits of TEE subsystem and may need to > > >> implement most of the requirements in the back-end driver. Also, as > > >> discussed above, the UAPI is not suitable for capability-based use cases. > > >> We proposed a new set of ioctl calls for SMC-Invoke driver. > > >> Please work constructively to evolve TEE subsystem. There is no specific definition here for TEE subsystem but rather it provides a generic user-space interface for clients to interact with underlying TEE implementation. > > >> In this series we posted three patches. We implemented a transport > > >> driver that provides qcom_tee_object. Any object on secure side is > > >> represented with an instance of qcom_tee_object and any struct exposed > > >> to TEE should embed an instance of qcom_tee_object. Any, support for new > > >> services, e.g. memory object, RPMB, userspace clients or supplicants are > > >> implemented independently from the driver. Why do we want to implement a separate platform driver for each of them when a single DT node is sufficient to tell presence of QTEE? It looks like an improper use of DT nodes. > > >> > > >> We have a simple memory object and a user driver that uses > > >> qcom_tee_object. > > > > > > Could you please point out any user for the uAPI? I'd like to understand > > > how does it from from the userspace point of view. > > > > Sure :), I'll write up a test patch and send it in next series. > > > > Summary. > > > > TEE framework provides some nice facilities, including: > > - uapi and ioctl interface, > > - marshaling parameters and context management, > > - memory mapping and sharing, and > > - TEE bus and TA drivers. > > > > For, MinkIPC, we will not use any of them. The only usable piece, is uapi > > interface which is not suitable for MinkIPC, as discussed above. Don't you want to support kernel clients to access QTEE services? I already see an example related to UEFI runtime variables access [4] as there wasn't a QTEE driver upstream to support that. [4] drivers/firmware/qcom/qcom_qseecom_uefisecapp.c -Sumit > > > > > > > >> > > >> Signed-off-by: Amirreza Zarrabi <quic_azarrabi@xxxxxxxxxxx> > > >> --- > > >> Amirreza Zarrabi (3): > > >> firmware: qcom: implement object invoke support > > >> firmware: qcom: implement memory object support for TEE > > >> firmware: qcom: implement ioctl for TEE object invocation > > >> > > >> drivers/firmware/qcom/Kconfig | 36 + > > >> drivers/firmware/qcom/Makefile | 2 + > > >> drivers/firmware/qcom/qcom_object_invoke/Makefile | 12 + > > >> drivers/firmware/qcom/qcom_object_invoke/async.c | 142 +++ > > >> drivers/firmware/qcom/qcom_object_invoke/core.c | 1139 ++++++++++++++++++ > > >> drivers/firmware/qcom/qcom_object_invoke/core.h | 186 +++ > > >> .../qcom/qcom_object_invoke/qcom_scm_invoke.c | 22 + > > >> .../firmware/qcom/qcom_object_invoke/release_wq.c | 90 ++ > > >> .../qcom/qcom_object_invoke/xts/mem_object.c | 406 +++++++ > > >> .../qcom_object_invoke/xts/object_invoke_uapi.c | 1231 ++++++++++++++++++++ > > >> include/linux/firmware/qcom/qcom_object_invoke.h | 233 ++++ > > >> include/uapi/misc/qcom_tee.h | 117 ++ > > >> 12 files changed, 3616 insertions(+) > > >> --- > > >> base-commit: 74564adfd3521d9e322cfc345fdc132df80f3c79 > > >> change-id: 20240702-qcom-tee-object-and-ioctls-6f52fde03485 > > >> > > >> Best regards, > > >> -- > > >> Amirreza Zarrabi <quic_azarrabi@xxxxxxxxxxx> > > >> > > > > > -- > With best wishes > Dmitry
