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@xxxxxxxxxx> 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
