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?
2. Adds whole TEE call sequence (ctx, session, shared memory etc.)
during "optee_probe".
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.
-Sumit
> - Jens
>
> >
> > -Sumit
> >
> > >
> > > Daniel.
