On 03/13/2015 05:39 PM, Javier González wrote:
Hi,
On 13 Mar 2015, at 11:38, Jens Wiklander jens.wiklander@linaro.org wrote:
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:
[...]
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.
Beware of the TOCTTOU problem [http://en.wikipedia.org/wiki/Time_of_check_to_time_of_use%5D%21
Still I can see how getting a list of installed service can be useful. For instance to manage services (install/remove/update...). But is such a service likely to be implemented in normal world? It could also be seen as a debugging feature. With OP-TEE it's quite easy to check if a TA is installed with "ls /lib/teetz/*.ta" and maybe it's just that we want to allow?