Hi All,
On 28/12/2018 16.46, Jens Wiklander wrote:
Hi Sumit,
On Fri, Dec 28, 2018 at 06:33:22PM +0530, Sumit Garg wrote:
On Fri, 28 Dec 2018 at 16:08, Ard Biesheuvel ard.biesheuvel@linaro.org wrote: Jens,
Is there any particular reason to wait indefinitely in "optee_supp_thrd_req" if there is no supplicant running? I think we should probably return as follows from "optee_supp_thrd_req" API in case no supplicant is available:
--- a/drivers/tee/optee/supp.c +++ b/drivers/tee/optee/supp.c @@ -88,10 +88,15 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, { struct optee *optee = tee_get_drvdata(ctx->teedev); struct optee_supp *supp = &optee->supp;
struct optee_supp_req *req = kzalloc(sizeof(*req), GFP_KERNEL);
struct optee_supp_req *req; bool interruptable; u32 ret;/* Return in case there is no supplicant available */if (!supp->ctx)return TEEC_ERROR_COMMUNICATION;req = kzalloc(sizeof(*req), GFP_KERNEL); if (!req) return TEEC_ERROR_OUT_OF_MEMORY;From a user space point of view it has been more useful to just wait until the supplicant starts to serve requests than polling the interface until the call succeeds. For this new use case it makes more sense to be able to return an error instead.
The proposed change is a user space API change, so we will need to do a bit more than that.
There are parts of kernel that need randomness before user space is ready.
Can't we move necessary logic for this to in kernel now that there is kernel service requiring TEE services?
I suppose there are even more services that would be better to be only optee<->kernel interface and not exposed as such to user space. One example of such would be mass storage encryption key or hardware rooted encryption for Linux keyring. Eg. replacement for TPM chip when TEE environment is available.
Thanks, Vesa Jääskeläinen