Hi,
On Fri, Mar 13, 2015 at 09:52:12AM -0400, Javier González wrote:
Hi,
On 13 Mar 2015, at 05:22, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi,
On Thu, Mar 12, 2015 at 01:56:17PM -0400, Javier González wrote: [...]
+/**
- TEE_IOC_CMD - pass a command to the specific TEE driver
- Takes tee_cmd_data struct which is passed to the specific TEE driver.
- */
+#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data)
Here, I would like to add TEE_IOC_TASK for stateless calls to the TEE.
TEE_IOC_CMD is stateless in the generic driver, it's up to the specific driver to add a state concept. Some requests through TEE_IOC_CMD could be handled without a state. Doesn't that cover what you're after?
Typically a client would have to open a “session” with the TEE that identifies that communication channel uniquely. This means that the client is in charge of holding that state when sending commands to the TEE.
I agree with that. But in the data passed to TEE_IOC_CMD are typically a sub command which have some meaning to the specific driver. Some sub commands could relate to some session, while others could be stateless.
With TEE_IOC_TASK I target use cases where the client requires one (and only one) command. In this way, the client would only send the command, and the driver would redirect the command to the default registered TrustZone driver (providing that more than one is instantiated simultaneously).
Hmm, this suggests that there's only one tee-device in /dev. I've always though that we would have one tee-device for each registered driver. By opening that device you get a communication channel to that specific driver.
[...]
If you all agree that TEE_IOC_LOAD_TS and TEE_IOC_GET_TS_LIST should be left for future revisions, it is OK. I think though that having the discussion about how OP_TEE could support this is necessary.
I think that TEE_IOC_LOAD_TS at this stage is something for the specific driver to deal with, in OP-TEE we're doing it with tee-supplicant.
I know that other TEEs are doing it too. I do not see a reason for not abstracting that behaviour and move specific OP-TEE parameters into an struct that is platform-dependent. I do that in the driver I first proposed for abstracting the structs handling OTZ parameters.
OP-TEE doesn't have something like TEE_IOC_LOAD_TS, OP-TEE OS load the TA via tee-supplicant so the client can't tell whether the application was just load or already resident.
I think we should try to keep the generic driver really simple in the first version. Both to save some time implementing it, but also to make the merge into the kernel easier. Once we have two or three specific drivers we know better what should be moved into the generic driver.
I'm not sure that TEE_IOC_GET_TS_LIST is needed. As Joakim pointed out earlier, a Trusted Service/Application is identified with a uuid which is just a sequence of byte with no particular meaning.
Yes. The question is whether we are in position to define some uuids for general operations.
I don't think it's needed for the first revision of the generic driver. If we see a need for making some uuid "well known" we can add that later.
Suppose that a client know that it would like to communicate with either uuid1 or uuid2, it could just try to do that and if the uuid isn't available an error will be returned. If the client would request a list of uuids first and discover that none where available, what would be the difference?
I guess that the difference is that we make the check explicit, therefore we make it part of the protocol to check the list.
What do you gain? To me it just looks like added complexity.
-- Regards, Jens