tee: add support for session's client UUID generation

[vesajaaskelainen]

TEE Client API defines that from user space only information needed for specified login operations is group identifier for group based logins.

REE kernel is expected to formulate trustworthy client UUID and pass that to TEE environment. REE kernel is required to verify that provided group identifier for group based logins is verified against calling processes group memberships.

Linux kernel does not provide common contex for application identifier, instead different security frameworks provide own means to defines application identifier for running process. Code includes place holder for such solutions but is left for later implementation.

TEE specification only defines that the information passed from REE environment to TEE environment is encoded into on UUID.

In order to guarantee trustworthiness of client UUID user space is not allowed to freely pass client UUID.

UUIDv5 form is used encode variable amount of information needed for different login types.

Signed-off-by: Vesa Jääskeläinen vesa.jaaskelainen@vaisala.com

This is related to: https://github.com/OP-TEE/optee_os/issues/3642

[vesajaaskelainen]

@jenswi-linaro I believe I have now addressed your comments and updated the PR accordingly.

I have moved application ID part as own RFC commit that could easily left out from initial submissions as that is open and could take longer period of time to have a solution.

For convenience of review I have created -delta branch to see individual edits: https://github.com/vesajaaskelainen/linux/commits/linaro-optee-login-checks-delta

[vesajaaskelainen]

@jenswi-linaro Now it should be better and splitted.

[vesajaaskelainen]

@jenswi-linaro updated. Removed "drivers: " from commit messages and moved Client UUID permission check and generation later.

Now there is ugly cast but I suppose it serves the purpose and I suppose the alignment is handled already.

[jenswi-linaro]

With this we can merge "tee: add support for session's client UUID generation" and "tee: optee: Add support for session login client UUID generation" to linaro-swg with the purpose of demonstrating the added test cases.

When it comes to "[RFC] drivers: tee: add support for app id for client UUID generation". I don't think that upstream is much interested in providing placeholders for out of tree changes. The aim should be to in the end have something that makes sense by itself upstream.

For these patches to land upstream I'd prefer if you can post these patches on the mailing lists, don't forget to add me and the AMD guys and anyone else you'd like to get the attention of in CC. If all goes well I'll pick up the first two patches for upstream. With the RFC patch we'll see what comes out of the discussion.

@vesajaaskelainen, does this make sense to you?

[vesajaaskelainen]

With this we can merge "tee: add support for session's client UUID generation" and "tee: optee: Add support for session login client UUID generation" to linaro-swg with the purpose of demonstrating the added test cases.

When it comes to "[RFC] drivers: tee: add support for app id for client UUID generation". I don't think that upstream is much interested in providing placeholders for out of tree changes. The aim should be to in the end have something that makes sense by itself upstream.

For these patches to land upstream I'd prefer if you can post these patches on the mailing lists, don't forget to add me and the AMD guys and anyone else you'd like to get the attention of in CC. If all goes well I'll pick up the first two patches for upstream. With the RFC patch we'll see what comes out of the discussion.

@vesajaaskelainen, does this make sense to you?

I agree that the RFC part is probably going to need much of discussion.

I think that merging two first would get us forward and then later the RFC part.

I can send the emails later this week. Need to rebase non-linaro branch to latest kernel version and test it out.

Do you want me to drop the RFC commit from this PR?

[jenswi-linaro]

Do you want me to drop the RFC commit from this PR?

It would be nice to keep it for reference. Perhaps @jforissier can take the first two commits and then close this PR manually.

[jforissier]

Do you want me to drop the RFC commit from this PR?

It would be nice to keep it for reference. Perhaps @jforissier can take the first two commits and then close this PR manually.

No problem.

[jforissier]

@jenswi-linaro do you want to provide some tags for the first two commits?

[jenswi-linaro]

I usually avoid doing that in order to avoid confusion with patches posted on the mailing lists.

Now I realize that I just did that in https://github.com/linaro-swg/linux/pull/72, but that PR is still far away from upstream and I didn't want to have to look through those patches again and again.

[jforissier]

I usually avoid doing that in order to avoid confusion with patches posted on the mailing lists.

OK, both ways are OK with me. I'm picking up the two patches and applying to our optee branch.