On 03/07/2024 13:36, Dmitry Baryshkov wrote:
On Tue, Jul 02, 2024 at 10:57:35PM GMT, Amirreza Zarrabi wrote:
<snip>
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.
Why can't you extend the TEE subsystem with those features ?
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.
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.
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.
<snip>
