On 2020-12-22 11:24, Elvira Khabirova wrote:
On Tue, 22 Dec 2020 08:50:56 +0000 Vesa Jääskeläinen via OP-TEE op-tee@lists.trustedfirmware.org wrote:
Hi,
On 2020-10-08 08:53, Jens Wiklander wrote:
Hi Sumit,
On Wed, Oct 7, 2020 at 11:27 AM Sumit Garg sumit.garg@linaro.org wrote:
Hi Jens,
On Thu, 17 Sep 2020 at 19:10, Sumit Garg sumit.garg@linaro.org wrote:
Since the addition of session's client UUID generation via commit [1], login via REE kernel method was disallowed. So fix that via passing nill UUID in case of TEE_IOCTL_LOGIN_REE_KERNEL method as well.
Fixes: e33bcbab16d1 ("tee: add support for session's client UUID generation") [1] Signed-off-by: Sumit Garg sumit.garg@linaro.org
drivers/tee/tee_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Would you like to pick up this fix?
Thanks for the reminder. This looks good to me. I'll pick up this unless someone objects. Vesa, does this look good to you too?
Cheers, Jens
Sorry I have been away for a while from the mailing list.
It seems that this is merged -- only thing that came to my mind with this is that:
If we have some kernel protected keys or so -- should we have separate client UUID for kernel operations.
Like when TEE_IOCTL_LOGIN_REE_KERNEL is given then client UUID would be generated for "kernel".
This way we can make sure that kernel owned keys stays for kernel. Nil UUID is kinda reserved for public login.
Isn't this unnecessary? According to the TEE Internal Core API Specification, TEE_Identity, a data type that "defines the full identity of a Client", consists of a UUID *and* one of the TEE_LOGIN_XXX constants. Therefore, TEE_LOGIN_PUBLIC with a nil UUID is a different client than TEE_LOGIN_REE_KERNEL with a nil UUID.
Not sure yet.
"Generic calls" to TEE from kernel without any context could go with TEE_LOGIN_REE_KERNEL:<nil UUID>.
We can extend that while we go forward when the TEE Identity is used in the TA to control which party is allowed to use the service OR if the service is aware if identity and just stores ownership for the data/secret and then checks that it is matching when being accessed again.
I am wondering if we have cases within kernel were we need to be aware on the path were the request is coming from.
Sumit Garg has been working on TEE based Trusted Keys and at least there could be own "context".
Then we have Crypto API where one can do some operations: https://www.kernel.org/doc/html/v5.10/crypto/api-akcipher.html#c.crypto_akci...
But probably the API itself does not bring context but where it is used from.
Only way to distinguish those from each other would be TEE_LOGIN_REE_KERNEL:<UUID>.
I don't think there is immediate need to change what is currently there -- more on the use case when the need arises.
Thanks, Vesa Jääskeläinen