Re: [PATCH v1 2/2] hwrng: add OP-TEE based rng driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux