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 04:34, Jerome Forissier jerome.forissier@linaro.org wrote:
Hello Valentin,
On Thu, Mar 5, 2015 at 12:27 PM, Valentin Manea valentin.manea@huawei.com wrote: Hi Jerome, On 05.03.2015 12:19, Jerome Forissier wrote:
Hi all,
I second Emmanuel's concerns. It seems to me that with the current definitions, the generic driver would almost be an empty pipe, and add little value to the solution.
In my opinion, the generic driver has to define a precise interface and not allow opaque commands that would depend on the TEE solution. Otherwise what assumptions can the user space make when it opens the device? Should it probe the driver to detect which language it speaks? Better have one driver for each "language" (GlobalPlatform or whatever).
So I would drop the "generic driver" and focus on a "GlobalPlatform TEE driver". If someone needs to implement a different interface than GP, then he would write another driver (is it something we have to consider short-term?)
[...] If you put it like that I don't see much value in a GP driver and I would guess upstream also wouldn't see value in it anyway, this is the reason I was proposing something more generic. But to give a specific example for my reasons: how do you implement secure storage? In Huawei TEE case there is a secure storage daemon that has a separate channel to TEE - this channel is outside GP specifications completely and it's homebrew. This is just one short example, but there enough of these implementation details where just saying we want a GP driver would not be enough and a separate channel would be created between user space and kernel. So basically the GP TEE driver would not bring enough value.
OK, this make sense. Among non-GP operations that would have to go through the driver, there's also the loading of TA binaries for instance. Still, my point is: can we try to define the operations (i.e., ioctls essentially) as precisely as we can, so that user space code is as simple and portable (on different TEEs with the same generic driver) as possible? We would define all GP operations (create session, invoke command...) plus what's needed to support them (helpers for secure storage, TA loading, shared memory management...). We would still allow private commands to go through the generic driver to the specific backend.
PS: I think you are in the same building as the Trustonic guys, maybe inviting them would not be a bad idea - while I wrote most of the driver, I would rather not talk for them. If you don't know anybody I can suggest a few contacts.
Good idea. Please send me some names in PM. I can contact them and suggest they join the list.
-- Jerome
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev