On Thu, Mar 5, 2015 at 4:24 PM, Javier González javigon.napster@gmail.com wrote:
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?
ARM describes SMC Calling Convention in http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028a/index.h.... I think we should focus on covering "Trusted Application Calls" and "Trusted OS Calls" since the rest can very well be managed outside the TEE on some platforms. ARM-TF manages the PSCI interface for instance.
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.
What is a "monitor"?
SMCs aren't different on ARMv8 compared to ARMv7, at least from a normal world point of view. Once example where SMCs already are used on ARMv8 is the usage of PSCI.
As Valentin mentioned, we need a standardized way for the specific driver to identify itself (type and version) and probably the same for the Trusted OS too. This can be part of the interface provided by the "common" driver if we require the "specific" driver to supply this information when registering.
Regards, Jens