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

_______________________________________________
Tee-dev mailing list
Tee-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/tee-dev