Hi Javier,
On Tue, Mar 31, 2015 at 5:34 PM, javigon.napster@gmail.com wrote:
From: Javier González javier@javigon.com
Hi,
Here's the proposal I described the other day. The goal is to provide support for kernel submodules. I encountered some challenges that I would like to discuss with you:
- Command and parameters: In the patchset Jens sent, all ommunication with the TEE is opaque. This is good for user space but not for kernel submodules. I propose adding a tee_cmd and tee_parameters. The value is opaque and can be flourished by the TEE if necessary.
That would be inconvenient for at least OP-TEE. In the current state where marshaling the parameters in user space, updating some pointers and shared memory references in the driver and then passing it on to secure world. What you're proposing would be to first marshal once in user space, and then once more in kernel space using two different ways for formatting the parameters.
Command list: If we want kernel submodules to use the TEE as they use TPM we need a list of commands that all (most) TEEs would support. We need to have this discussion and maybe bring more parties to it. Probably Global Platform's use cases are a good place to start.
Session: I miss the concept of a session. The responsability is very similar to tee_filp. I would suggest to change the name to tee_session. I believe that it makes it more clear.
In the OP-TEE case the tee_filp corresponds to a TEE_Context, if we call it tee_session in the kernel it will be confusing as we store the TEE sessions inside the context.
The TEE subsystem is very thin and doesn't provide much, except some helpers to create a device and manage shared memory. But it solves one other problem common to all tee drivers, it provides a place in the kernel tree where to put the driver. I think it's an advantage to make the TEE subsystem in small steps. Currently the the TEE subsystem is a bit more than 1100 lines of code and not very complicated.
I think that what's currently on github is very close to what we need for the first step (I have a couple of small patches that I'd like to get in also, but nothing dramatic). I would prefer we didn't add more generic features to the subsystem and instead focused on getting what we have in shape to upstream.
- Position: I like sec-hw :) But we need to bring at least another piece of secure hardware to this location in order to motivate a new submodule. TPM is the most obvious. We would then need to move all into /drivers/sec-hw/?? I assume your do not like trustzone since it is very specific for some of you - is tee good? I did not want to send a patch without discussing the naming first.
Are you proposing storing it under /drivers/tee instead of /drivers/sec-hw? I'm in favor of that since tee describes better what we're doing. We are communicating with software running in the secure environment, not interfacing with some secure crypto device etc.
Finally, regarding the process: is sending patches, discussing, and then applying to github a process you all fell comfortable with? Suggestions are welcome.
Fine with me. I think it would be good if we did all the merging on github via pull requests, that way it's very clear what will be merged.
Best, Javier
Javier González (1): tee: add tee operations for kernel submodules
drivers/sec-hw/tee.c | 175 +++++++++++++++++++++++++++++++++++++++-- drivers/sec-hw/tee_private.h | 14 ++++ include/linux/sec-hw/tee.h | 98 ++++++++++++++++++++++- include/linux/sec-hw/tee_drv.h | 11 --- 4 files changed, 279 insertions(+), 19 deletions(-)
-- 1.9.1
Tee-dev mailing list Tee-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/tee-dev