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