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