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.
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).
There will be requests into secure world that will not go via this generic driver. PSCI is one example. On ARMv8 PSCI is handled in ARM-TF at EL3, but on ARMv7 it will probably be handled by the secure OS. If we compare with what's defined in SMC Calling Convention I think this driver will only be dealing with stuff that falls in the SMC ranges for Trusted Application and Trusted OS calls. The generic driver will not try to enforce that in any way since it doesn't even know what an SMC is.
Agreed.
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.
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.
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.
-- Regards, Jens
Best, Javier