Return-Path: Received: from mail-ua1-f67.google.com ([209.85.222.67]:47074 "EHLO mail-ua1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727078AbeLaKgF (ORCPT ); Mon, 31 Dec 2018 05:36:05 -0500 Received: by mail-ua1-f67.google.com with SMTP id v24so8532613uap.13 for ; Mon, 31 Dec 2018 02:36:04 -0800 (PST) MIME-Version: 1.0 References: <1545908831-25910-1-git-send-email-sumit.garg@linaro.org> <1545908831-25910-3-git-send-email-sumit.garg@linaro.org> <20181228144610.GA21561@jax.urgonet> <79744651-991d-ff44-2238-96721ff9bc18@gmail.com> In-Reply-To: <79744651-991d-ff44-2238-96721ff9bc18@gmail.com> From: Sumit Garg Date: Mon, 31 Dec 2018 16:05:52 +0530 Message-ID: Subject: Re: [PATCH v1 2/2] hwrng: add OP-TEE based rng driver To: =?UTF-8?B?VmVzYSBKw6TDpHNrZWzDpGluZW4=?= Cc: Jens Wiklander , Ard Biesheuvel , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Devicetree List , mpm@selenic.com, Herbert Xu , Rob Herring , Mark Rutland , Arnd Bergmann , Greg Kroah-Hartman , Daniel Thompson , Bhupesh Sharma , tee-dev@lists.linaro.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-crypto-owner@vger.kernel.org List-ID: On Sun, 30 Dec 2018 at 20:29, Vesa J=C3=A4=C3=A4skel=C3=A4inen 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 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 =3D tee_get_drvdata(ctx->teedev); > >> struct optee_supp *supp =3D &optee->supp; > >> - struct optee_supp_req *req =3D kzalloc(sizeof(*req), GFP_KERNE= L); > >> + 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 =3D 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 interfac= e > > until the call succeeds. For this new use case it makes more sense to b= e > > 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=C3=A4=C3=A4skel=C3=A4inen