On Sun, 30 Dec 2018 at 20:29, Vesa Jääskeläinen <dachaac@xxxxxxxxx> wrote:
>
> 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?
>
Yes it is exactly what this optee-rng kernel module is trying to achieve.
> 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.
>
Agree, for such use-cases we are working on adding TEE bus support so
that kernel drivers would be able to communicate with TEE based
devices.
-Sumit
> Thanks,
> Vesa Jääskeläinen
