Re: [PATCH v4 1/1] ArmPkg/OpteeLib: Add APIs to communicate with OP-TEE

[Leif Lindholm <leif.lindholm@linaro.org>]

On Thu, Oct 18, 2018 at 02:43:37PM +0530, Sumit Garg wrote:
> On Thu, 18 Oct 2018 at 14:04, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> >
> > On Thu, Oct 18, 2018 at 12:59:32PM +0530, Sumit Garg wrote:
> > > > So, looking at the OpTee sources, TEE_UUID is defined as a struct, to
> > > > exactly the same layout as the EFI_GUID type (which is a typedef of
> > > > the GUID struct). Could we add a OPTEE_UUID typedef for the same
> > > > struct in OpteeLib.h?
> > > >
> > > > Since it comes in as an OPTEE_MESSAGE_PARAM_VALUE, alignment is
> > > > already guaranteed to be 64-bit.
> > > >
> > > > (This also deserves a comment explaining how EFI_GUID basically
> > > > follows rfc4122, but uses little-endian for the timestamp fields.)
> > >
> > > Actually, OP-TEE also uses little-endian format for timestamp fields.
> > > You can refer to [1] for conversion from network byte order (octets)
> > > to little-endian and vice-versa.
> > >
> > > So for communications among secure world and non-secure world it uses
> > > network byte order for UUID/GUID to comply with rfc4122.
> > >
> > > [1] https://github.com/OP-TEE/optee_os/blob/master/core/tee/uuid.c
> >
> > Huh, ok. That's good to know.
> > It does however not change my comments. Since we're dealing with data
> > structures of a known layout, I am not a fan of treating them as byte
> > arrays.
> >
> 
> But calling UUID struct with swapped timestamp as OPTEE_UUID would
> also be misnomer. I am not sure regarding appropriate naming for that
> struct.

That's a fair point. We could call it RFC4122_UUID for now.

There could even be a case to add that to BaseLib at some point (but
probably not while there is only one user).

Regards,

Leif

> On the other hand, we have byte array of 16 octets as per network byte
> order complying with rfc4122 which also doesn't imply swapped
> timestamp.
> 
> -Sumit
> 
> > /
> >     Leif