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.
