On Fri, Mar 13, 2015 at 12:39:49PM -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.
Good for me. Then we need to specify what the client is suppose to take care of in form of commands. This is, it is not only defining a command that express the statelessness, but defining what the client should keep for future communications.
Yes, that's a protocol between the client and the specific driver, the generic driver shouldn't care about it. For OP-TEE I guess we'll use a twist of the TEESMC interface.
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.
You are right. It makes more sense to have several tee-devices to support platform-specific libraries (e.g., tee-suplicant).
That also means that we can have different permissions on different devices to make it harder for user space to DOS secure world.
[...]
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.
My point is that you make it more difficult for applications to mishandle error codes. If checking a list of supported trusted services is part of the protocol then applications are more likely to ensure that the service exists before sending the command. They do something similar in TPM to check the version of the TPM (v.1.2, or 2.0) which is a good example of how applications would look at different TEE-frameworks.
As Jerome points out, there's the timing issue. But it also sounds like "nice to have", perhaps we can wait with this until after the first version?
-- Regards, Jens