Hi all,
Thanks Joakim for setting the mailing list up :)
My vision of the driver lines up with Valentin’s. I will give a general description; we can get into details as we start agreeing on some basic design aspects.
I support a generic interface that abstracts different tee drivers underneath it and APIs above it. I agree in that we should have a well-defined common ioctl structure to make specific drivers comply with it. The ioctl maps then to an in-kernel common interface. This allows to have (i) a user space GP API implementation that uses the ioctl interface, as well as other components and interfaces (e.g., tee-supplicant); and (ii) kernel submodules directly using the in-kernel interface to which the generic ioctl maps. Examples of kernel submodules that would benefit from this include IMA and the keyring, which already use TPM for specific sensitive tasks. A generic TrustZone driver in the kernel would even open for a soft-TPM implementation based on TrustZone for ARM devices. This is indeed and examples of a non-GP API that could be supported, also for user space applications. I cannot see other way to expose TrustZone services to kernel submodules, but I am happy to be proven wrong.
In my view, the simpler the common interface is, the better. I also agree that some generic commands should be defined. While we risk that the specific TEE implementation does not implement all these commands, there are some operations that must be there (e.g., open, close, allocate shared memory). Here, I think that the main challenge is that TrustZone services are very scattered among frameworks, which makes functionality difficult to generalize (and at the same time makes GP more attractive). However, the fact that GP's API is limited in use cases and that it has already changed many times (4 if I remember properly) makes it difficult to argue for it being upstream. If we start with a small subset of functionality beyond GP traditional use cases (e.g., trusted storage, integrity measurements, reference monitor (?)) based on our experience, we might be able to have a place to start. What are your thoughts here?
Regarding Joakim’s and Jens’ architecture, I think that it captures the essence of this design. One suggestion I have is also decoupling the platform-specific monitor from the specific driver. In my experience this is challenging, but design-wise, if we could have smc handlers for different platforms available to different tee-specific implementations, it would be ideal. This would also simplify support for some ARMv8 smc calls that need to be issued via pointer access.
Best,
Javier
On 5 Mar 2015, at 03:52, Jean-michel DELORME jean-michel.delorme@st.com wrote:
Hi all,
To continue the discussion and to clarify some points in my mind about the objectives to build a common layer or "generic" driver (GP or not) which is a "simple" (should be clarified) way to pass the opaque data to a backend without a real added value.
If we keep the proposed modular design (seems the case today), the "generic" part can be abstract to manage the notions of context, session, command and also shared memory (RPC-like API). This approach is compliant with the GP TEEC API or other API which expects to manage the remote services. Basically, based on the well-defined back-end call back API (with the mandatory and optional methods), the common part will be in-charge to manage the life cycle of the underlying managed objects and the back-ends will be and should be a simple component to implement the specific part.
Expected service from the back-ends:
- power management aspect
- inter domain memory management (including SHM public management and cache management)
- firmware manager
- communication agent
- API manipulated interface the manage the opaque data (GP specific aspects will be done here)
All these points (design approach) are basically covered by our current solution (GP oriented). We need to remove the GP specific aspects and to move the tee_supplicant services to the back-end.
You share my view or my vision is completely wrong...
Br, Jean-Michel
-----Original Message----- From: tee-dev-bounces@lists.linaro.org [mailto:tee-dev-bounces@lists.linaro.org] On Behalf Of Valentin Manea Sent: Thursday, March 05, 2015 12:15 PM To: Emmanuel MICHEL; tee-dev Subject: Re: [Tee-dev] Interface proposal
HI Emmanuel, On 05.03.2015 11:37, Emmanuel MICHEL wrote:
Hello Valentine,
Just for me to understand:
" To be more specific the ioctl structure format should be somewhat common."
Today we use GP interface. With which other api do you want to communize the interface ? Thanks
GP is just an API, the binary format is implementation specific. However in the specific case of IOCTLs we are talking about send some binary data from user space to kernel which will forwarded to TEE. Since we are trying to build a common layer I think this should have some comonalities to cover the generic TEEs. I would guess people upstream too would like it more if we didn't just say GP is the only interface.
Valentin
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev