Hello,
There are lots of uint64_t in the proposal, and I wonder how it will behaves on 32bits platforms, in terms of performances, ease to use,...
This interface is not intended to be used directly by client code, instead it's supposed to be wrapped in a client lib. I'm trying to follow the guide lines in https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt to avoid the need of having one 64-bit and one 32-bit api.
Thanks Jens for the doc. However, it does not really answer: do you know if there are any performance drop using u64 types instead of native type on 32bits platforms? Or we simply don't care?
Pascal.
On 16 March 2015 at 10:26, Jens Wiklander jens.wiklander@linaro.org wrote:
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