Hi,
On 01 Apr 2015, at 11:35, Jens Wiklander jens.wiklander@linaro.org wrote:
On Wed, Apr 01, 2015 at 09:47:26AM +0200, javigon wrote:
Hi Jens,
On 01 Apr 2015, at 09:20, Jens Wiklander jens.wiklander@linaro.org wrote:
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.
Yes. We could maintain two different functions for it, so that user space communication through ioctl only needs to be formatted once. I do not know the internals of OP-TEE, but this works nice in OTZ; when a command and parameters reach the specific driver, they are formatted so that the TEE can understand it while the interdace is the same for the kernel.
OK, where should the formatting be done? In a new tee_cmd_kernel() callback?
Sounds good to me. Here we parse the command and add the parameter list.
- 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.
Ok. Can we call it tee_context then, so that it describes it better when not using ioctl?
OK
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.
Agreed.
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.
Ok. I would still like to add the in-kernel functionality. I think that it is a big part of the contribution providing the framework for in-kernel TEE operations. It would also help maintaining an agnostic but not opaque interface. We can look at trusted services later on.
OK
- 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.
My initial though was a trustzone driver, therefore the sec-hw idea. Given the move towards tee-agnostic I am now between /drivers/tee and /drivers/sec-hw/tee - since hardware is still necessary to support the TEE. But I am more and more open to having /drivers/tee :)
:-)
If the rest agree, let’s do it then :)
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.
Sounds good. But I assume we maintain RFC in patch mailing list?
Sure.
-- Regards, Jens
Best, Javier