On Mon, 7 Jan 2019 at 06:32, Sumit Garg <sumit.garg@xxxxxxxxxx> wrote:
>
> On Fri, 4 Jan 2019 at 18:33, Jens Wiklander <jens.wiklander@xxxxxxxxxx> wrote:
> >
> > On Fri, Jan 4, 2019 at 1:02 PM Sumit Garg <sumit.garg@xxxxxxxxxx> wrote:
> > >
> > > On Fri, 4 Jan 2019 at 16:31, Jens Wiklander <jens.wiklander@xxxxxxxxxx> wrote:
> > > >
> > > > On Fri, Jan 4, 2019 at 7:39 AM Sumit Garg <sumit.garg@xxxxxxxxxx> wrote:
> > > > >
> > > > > On Thu, 3 Jan 2019 at 22:44, Daniel Thompson <daniel.thompson@xxxxxxxxxx> wrote:
> > > > > >
> > > > > > On Fri, Dec 28, 2018 at 02:41:01PM +0530, Sumit Garg wrote:
> > > > > > > On Thu, 27 Dec 2018 at 19:10, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
> > > > > > > >
> > > > > > > > On Thu, 27 Dec 2018 at 12:08, Sumit Garg <sumit.garg@xxxxxxxxxx> wrote:
> > > > > > > > >
> > > > > > > > > Add bindings for OP-TEE based optional hardware random number
> > > > > > > > > generator identifier property. It could be used on ARM based devices
> > > > > > > > > where entropy source is not accessible to normal world (linux in this
> > > > > > > > > case).
> > > > > > > > >
> > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@xxxxxxxxxx>
> > > > > > > > > ---
> > > > > > > > > Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt | 4 ++++
> > > > > > > > > 1 file changed, 4 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> > > > > > > > > index d38834c..e3a4c35 100644
> > > > > > > > > --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> > > > > > > > > +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> > > > > > > > > @@ -20,6 +20,9 @@ the reference implementation maintained by Linaro.
> > > > > > > > > "hvc" : HVC #0, with the register assignments specified
> > > > > > > > > in drivers/tee/optee/optee_smc.h
> > > > > > > > >
> > > > > > > > > +- rng-uuid : Optional OP-TEE based RNG service identifier in case
> > > > > > > > > + hardware entropy source is not accesible to normal world
> > > > > > > > > + (Linux).
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Example:
> > > > > > > > > @@ -27,5 +30,6 @@ Example:
> > > > > > > > > optee {
> > > > > > > > > compatible = "linaro,optee-tz";
> > > > > > > > > method = "smc";
> > > > > > > > > + rng-uuid = "ab7a617c-b8e7-4d8f-8301-d09b61036b64";
> > > > > > > >
> > > > > > > > If OP-TEE is going to expose devices in this way, it should be modeled
> > > > > > > > more like a bus driver, i.e., sub-nodes that represent the devices,
> > > > > > > > with compatible strings, and perhaps even 'reg' properties for the
> > > > > > > > UUIDs.
> > > > > > > >
> > > > > > >
> > > > > > > This is something Daniel also suggested during our discussion. But we
> > > > > > > agreed to discuss in upstream to get more feedback.
> > > > > > >
> > > > > > > I think generic TEE should be modelled as a bus driver with devices
> > > > > > > identified via UUIDs, probably queried from underline implementations
> > > > > > > like OP-TEE regarding which resident devices (pseudo-TA UUIDs) it
> > > > > > > supports. Then this list of device UUIDs can be compared against child
> > > > > > > driver's UUID as part of match callback during driver registration.
> > > > > > > Also the child driver could maintain list of device UUIDs which it
> > > > > > > supports.
> > > > > > >
> > > > > > > If we go via this approach we may not require device tree entry for
> > > > > > > corresponding device UUIDs.
> > > > > >
> > > > > > That's pretty much aligned with my thinking.
> > > > > >
> > > > > > Having said that I had wondered whether all TEEs would be prepared to
> > > > > > describe the set of available UUIDs since AFAIK UUID enumeration isn't
> > > > > > part of the GlobalPlatform standards so it is not implemented by GP
> > > > > > based TEEs (such as OP-TEE).
> > > > > >
> > > > > > Is it feasible to extend OP-TEE to enumerate the available UUIDs?
> > > > > > If nothing else can it provide an (optional) pseudo TA to provide such a
> > > > > > service? Personally I'd be OK with a kernel TEE bus infrastructure that
> > > > > > mandated such a service (e.g. a TEE that does not provide the service
> > > > > > can only interact with TEE from userspace).
> > > > > >
> > > > >
> > > > > Following is the kernel interface for OP-TEE device enumeration that I
> > > > > would like to propose:
> > > > >
> > > > > /*
> > > > > * Get next OP-TEE based kernel device
> > > > > *
> > > > > * Secure world can provide support for resident kernel devices/services
> > > > > * as pseudo/early trusted applications. So this function is used to
> > > > > * enumerate OP-TEE based kernel devices.
> > > > > *
> > > > > * Call register usage:
> > > > > * a0 SMC Function ID, OPTEE_SMC_GET_NEXT_DEVICE
> > > > > * a1-6 Not used
> > > > > * a7 Hypervisor Client ID register
> > > > > *
> > > > > * Possible return values:
> > > > > *
> > > > > * OP-TEE OS returns next device UUID.
> > > > > * a0 OPTEE_SMC_RETURN_OK
> > > > > * a1-4 Device UUID
> > > > > * a5-7 Preserved
> > > > > *
> > > > > * OP-TEE OS does not recognize this function.
> > > > > * a0 OPTEE_SMC_RETURN_UNKNOWN_FUNCTION
> > > > > * a1-7 Preserved
> > > > > *
> > > > > * OP-TEE OS done with device enumeration.
> > > > > * a0 OPTEE_SMC_RETURN_ENOTAVAIL
> > > > > * a1-7 Preserved
> > > > > */
> > > > > #define OPTEE_SMC_FUNCID_GET_NEXT_DEVICE 15
> > > > > #define OPTEE_SMC_GET_NEXT_DEVICE \
> > > > > OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_NEXT_DEVICE)
> > > > >
> > > > > Also at OP-TEE end, we should add additional TA_FLAG_KERNEL_DEVICE to
> > > > > detect particular pseudo/early TA as a kernel device during
> > > > > enumeration.
> > > >
> > > > I'd rather provide this enumeration via a pseudo TA, to keep the SMC
> > > > interface as small as possible. The pseudo TA can be optional, if it's
> > > > not available then there's no need to try to instantiate any dependent
> > > > drivers either.
> > > >
> > >
> > > I did thought about having a pseudo TA but following are some
> > > negatives to this approach:
> > > 1. Where do we specify UUID for this pseudo TA? Should it come from devicetree?
> >
> > This should be a well known UUID, provided in the .h file describing the TA.
> >
>
> Ok.
>
> > > 2. Adds whole TEE call sequence (ctx, session, shared memory etc.)
> > > during "optee_probe".
> >
> > Yes, is that a problem?
> >
>
> Not a problem but simply fast call interface is comparatively quicker.
>
> > > 3. This pseudo TA would be exposed to user-space as well. I am not
> > > sure if we would like user-space to access kernel device specific
> > > info.
> >
> > Doesn't matter, that's not a secret. We can assume that an attacker
> > already know the UUID of whatever TA it will target.
> >
>
> Okay then as per your suggestion will implement enumeration via pseudo
> TA approach.
>
But this also requires some kind of well-known GUID for the RNG function, no?
