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

[Sumit Garg <sumit.garg@linaro.org>]

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.

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