Re: [PATCH v1 1/2] dt/bindings: add bindings for optional optee rng-uuid property

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

 



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.

-Sumit

>
> Daniel.



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux